#10903: Update Singular to 3-1-3-3
-------------------------------------------------------------------------+--
Reporter: malb |
Owner: tbd
Type: defect |
Status: needs_info
Priority: critical |
Milestone: sage-4.7.2
Component: packages |
Resolution:
Keywords: singular SageDays34 sd34 |
Work_issues:
Upstream: N/A |
Reviewer: Martin Albrecht, Volker Braun, Simon King
Author: Burcin Erocal, Martin Albrecht, Volker Braun, Simon King |
Merged: sage-4.7.2.alpha4
Dependencies: #11339 |
-------------------------------------------------------------------------+--
Comment(by leif):
Replying to [comment:113 jdemeyer]:
> Replying to [comment:110 leif]:
> > Replying to [comment:108 jdemeyer]:
> > > New spkg needs review:
[http://boxen.math.washington.edu/home/jdemeyer/spkg/singular-3-1-3-3.p1.spkg].
See [attachment:singular-3-1-3-3.p0-p1.diff] for changes.
> >
{{{
* Exit when `patch` fails. We do not print an error message, patch is
verbose enough by itself.
}}}
> >
> > Not true. `patch`'s error messages do not start with `Error` nor
`Failed`, such that it's hard to find out which spkg actually failed to
build / install in parallel builds.
>
> What do you mean with this? How is the message
{{{
Error: Patch failed to apply.
}}}
> more clear than something like
{{{
1 out of 7 hunks FAILED -- saving rejects to file
sage/rings/number_field/number_field_element.pyx.rej
}}}
It isn't more clear (the "Error: ..." would be printed ''in addition''
anyway, although an "ordinary" user would perhaps not know what a hunk is
or the message is all about), but you can easily grep for it, so ''every''
error message should start with "Failed" or (preferably) "Error".
(Volker, btw., the new ATLAS spkg is an IMHO poor counterexample to that,
as it raises unhandled exceptions such that one gets tracebacks instead of
meaningful error messages.)
The Sage library, which is built in parallel ''by default'', is also a bad
exception to this; it's often hard to see what really failed, not to
mention the odd warnings about `-Wstrict-prototypes` not being valid for
C++.
[[BR]]
> In any case, I don't see what this has to do with parallel builds.
Well, the screen output (and hence `install.log`) is pretty messed up in
parallel builds, and `make` usually doesn't stop immediately if one spkg
fails to build, but continues and waits for other jobs to finish. [Another
issue is that `stdout` and `stderr` frequently get "out of sync".]
To see what went wrong or which spkgs failed to build / didn't pass the
(self-)test suite, one can usually do
{{{
#!sh
$ egrep '^(Error|Failed) ' spkg/logs/*
}}}
with variations on `-i`, `-h`, `-n` and `-A/B/C...` etc.
It wouldn't be bad to add something similar to the top-level `Makefile`;
since we always ''append'' to the logs, we could create a fresh temporary
log file upon every build and let `sage-spkg` write to it whenever a build
or running `spkg-check` failed, such that an informative summary can be
printed at the end, at least on errors. (We could also log the so far
successfully built spkgs somewhere, such that one can `tail -f` that file,
perhaps even with timings or date/time, "i/N spkgs built".)
[[BR]]
> Can anybody tell me how we should proceed?
Well, it's a minor issue of course. But we should IMHO avoid such in the
future.
I still cannot really tell whether this spkg (along with the patches)
causes ''more'' doctests to fail on Linux PPC64 (the Skynet machine
Silius; SLES 11.1, POWER7), since I've experimented with various things on
that machine, and I haven't yet had the time to reliably compare builds
which really only differ w.r.t. this ticket (and #11339).
In case this ticket should cause more problems on that platform, we could
(hopefully) fix these on a follow-up, since there are other spkgs which
apparently are still broken on it (also depending on the compiler version
and options), so building Sage there is currently pretty experimental
anyway.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10903#comment:119>
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.
