Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#9274 closed defect (fixed)

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

Reported by: was Owned by: GeorgSWeber
Priority: blocker Milestone: sage-4.5
Component: build Keywords:
Cc: drkirkby, jhpalmieri Merged in: sage-4.5.alpha4
Authors: Mitesh Patel, John Palmieri Reviewers: Robert Miller
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description

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

Attachments (4)

deps (17.7 KB) - added by mpatel 9 years ago.
Updated spkg/install/deps based on 4.5.alpha1.
deps.diff (16.9 KB) - added by mpatel 9 years ago.
Diff of spkg/install/deps vs. 4.5.alpha1.
deps-new (18.1 KB) - added by jhpalmieri 9 years ago.
rebased against 4.5.alpha3
deps-new.diff (16.8 KB) - added by jhpalmieri 9 years ago.

Download all attachments as: .zip

Change History (21)

comment:1 Changed 9 years ago by mpatel

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

Changed 9 years ago by mpatel

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

Changed 9 years ago by mpatel

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

comment:2 Changed 9 years ago by mpatel

  • Cc drkirkby jhpalmieri added
  • Milestone changed from sage-4.5 to sage-5.0
  • Priority changed from major to minor
  • Status changed from new to needs_work

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.

comment:3 Changed 9 years ago 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.

comment:4 Changed 9 years ago by rlm

  • Work issues set to needs rebasing on top of not yet existing release

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?

comment:5 Changed 9 years ago by rlm

  • Milestone changed from sage-5.0 to sage-4.5
  • Priority changed from minor to blocker

comment:6 Changed 9 years ago by drkirkby

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

comment:7 follow-up: Changed 9 years ago by jhpalmieri

Is this as good a place as any to work out dependencies for glpk? (See http://trac.sagemath.org/sage_trac/ticket/9312#comment:24.)

comment:8 in reply to: ↑ 7 Changed 9 years ago by rlm

  • Work issues changed from needs rebasing on top of not yet existing release to needs rebasing on sage-4.5.alpha3

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.

Changed 9 years ago by jhpalmieri

rebased against 4.5.alpha3

Changed 9 years ago by jhpalmieri

comment:9 Changed 9 years ago by jhpalmieri

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

comment:10 Changed 9 years ago by jhpalmieri

  • Status changed from needs_work to needs_review

comment:11 Changed 9 years ago by rlm

  • Authors set to Mitesh Patel, John Palmieri
  • Reviewers set to Robert Miller
  • Status changed from needs_review to positive_review

comment:12 Changed 9 years ago by rlm

  • Merged in set to sage-4.5.alpha4
  • Resolution set to fixed
  • Status changed from positive_review to closed

comment:13 follow-up: Changed 9 years ago by jhpalmieri

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

comment:14 in reply to: ↑ 13 Changed 9 years ago by rlm

Replying to jhpalmieri:

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

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

comment:15 follow-up: Changed 9 years ago by ncohen

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

comment:16 in reply to: ↑ 15 Changed 9 years ago by drkirkby

Replying to ncohen:

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.

comment:17 Changed 9 years ago by mpatel

  • Work issues needs rebasing on sage-4.5.alpha3 deleted

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.
Note: See TracTickets for help on using tickets.