Update Singular to 3-1-3-3

[malb]

Singular spkg upgrade

Singular 3-1-2 fixes a critical bug, cf. #10902. There are more bugfixes in the newest stable release. We should update as soon as possible.

Sage libsingular upgrade

There are various issues where currRing is not correctly set. Some of these are triggered by refcounting the rings and freeing them when they are no longer needed, see the dependency ticket #11339.

Installation instructions

• Install: http://boxen.math.washington.edu/home/jdemeyer/spkg/singular-3-1-3-3.p1.spkg

• Apply the two dependency patches from #11339

• Apply: attachment: 10903_flat.patch

Depends on #11339

CC: @zimmermann6 @simon-king-jena

Component: packages: standard

Keywords: singular SageDays34 sd34

Author: Burcin Erocal, Martin Albrecht, Volker Braun, Simon King

Reviewer: Martin Albrecht, Volker Braun, Simon King

Merged: sage-4.7.2.alpha4

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

[vbraun]

Description changed:

--- 
+++ 
@@ -13,4 +13,6 @@

 * Apply the two dependency patches from #11339

-* **Apply:** [attachment: trac_10903_singular-3-1-3-3.patch](https://github.com/sagemath/sage-prod/files/10652282/trac_10903_singular-3-1-3-3.patch.gz), [attachment: trac_10903_singular-fixes.patch](https://github.com/sagemath/sage-prod/files/10652281/trac_10903_singular-fixes.patch.gz), [attachment: trac10903_fix_name.patch](https://github.com/sagemath/sage-prod/files/10652283/trac10903_fix_name.patch.gz), [attachment: trac10903_lgamma_doc.patch](https://github.com/sagemath/sage-prod/files/10652284/trac10903_lgamma_doc.patch.gz)
+* **Apply:** [attachment: trac_10903_singular-3-1-3-3.patch](https://github.com/sagemath/sage-prod/files/10652282/trac_10903_singular-3-1-3-3.patch.gz), [attachment: trac_10903_singular-fixes.patch](https://github.com/sagemath/sage-prod/files/10652281/trac_10903_singular-fixes.patch.gz), [attachment: trac_10903_docbuild_fix.patch](https://github.com/sagemath/sage-prod/files/10652285/trac_10903_docbuild_fix.patch.gz), [attachment: trac10903_lgamma_doc.patch](https://github.com/sagemath/sage-prod/files/10652284/trac10903_lgamma_doc.patch.gz)
+
+

[vbraun]

comment:85

I'm happy with trac10903_lgamma_doc.patch. Maybe Simon can quickly OK the trac_10903_docbuild_fix.patch, then we would be good to go?

[simon-king-jena]

Changed reviewer from Martin Albrecht, Volker Braun to Martin Albrecht, Volker Braun, Simon King

[simon-king-jena]

comment:86

Replying to @vbraun:

I'm happy with trac10903_lgamma_doc.patch. Maybe Simon can quickly OK the trac_10903_docbuild_fix.patch, then we would be good to go?

Sorry, I forgot to post before leaving office: Your patch manages to deduce the name of a deprecated Cython method. That certainly fixes the problem with the docs. With the patches applied as you stated it in the modified ticket description, both the doc tests and the references are fine.

Thus, positive review.

[d46d2cb1-860f-484d-8329-8ebfc9f5d004]

comment:87

It seems, that kernel mod_raw.cc lacks the following:

#if defined(ppcMac_darwin)
#define HAVE_ELF_SYSTEM
#endif

I already reported that upstream.

[jdemeyer]

Work Issues: memory usage

[jdemeyer]

comment:88

Unfortunately, I discovered another serious issue with the new Singular (#11339 + #10903): there is an enormous virtual memory usage regression in the test

sage -t -long devel/sage/sage/crypto/mq/sr.py

It used to need about 1.2GB virtual memory, with the new Singular it needs 3.0GB. I measured this by setting ulimit -v and checking whether the test succeeds, for example:

### The parentheses start a subshell such that the ulimit only affects
### that one command and not the whole shell.
$ ( ulimit -v 2500000; ./sage -t -long devel/sage/sage/crypto/mq/sr.py )
sage -t -long "devel/sage/sage/crypto/mq/sr.py"
[*****  0.000s] # doctest internal
[*****  0.000s] # doctest internal
[00029  0.040s] sr = mq.SR(Integer(1), Integer(1), Integer(1), Integer(4))
[...]
[03326  0.000s] from sage.crypto.mq.sr import AllowZeroInversionsContext
[03327  0.010s] sr = mq.SR(Integer(1),Integer(2),Integer(2),Integer(4))
[03328  0.000s] with AllowZeroInversionsContext(sr):
[03331  0.000s] sr._allow_zero_inversions
[*****  0.000s] # doctest internal
[*****  0.000s] # doctest internal
[*****  0.000s] # doctest internal
[03355  0.010s] from sage.crypto.mq.sr import test_consistency

Singular error: no more memory
System 1604712k:1604712k Appl 1450267k/23501k Malloc 1032k/0k Valloc 1472736k/23501k Pages 368184/0 Regions 2932:2932

halt 14

         [114.3 s]

I don't know whether this issue is upstream or caused by some of the Sage library patches, but it is certainly serious enough not to merge this ticket.

As a reference: before this ticket, every test passed with 2.2GB of RAM, with the most memory used by

sage -t -long devel/sage/sage/schemes/elliptic_curves/heegner.py

[vbraun]

comment:89

Since the singular update fixes bugs that returned an incorrect result, I think the increased memory usage should be a separate ticket. If its a problem for the build bots, just pick a smaller #long example.

Or in other words: http://dilbert.com/strips/comic/1995-06-24

[jdemeyer]

comment:90

Volker, may I interpret your comment as "I think the increased memory usage is not a big deal and we should merge this ticket anyway"?

I don't know about the buildbot, I have not yet tested.

[vbraun]

comment:91

Yes, that is what I meant. The increased memory usage should not prevent us from merging the Singular update into sage-4.7.2.

Martin: Do you have any idea about what goes wrong in sr.py?

[jdemeyer]

comment:92

Replying to @vbraun:

Yes, that is what I meant. The increased memory usage should not prevent us from merging the Singular update into sage-4.7.2.

I totally understand what you mean but I disagree. It's always hard when one has to make a choice of bugs: this ticket certainly fixes bugs but also introduces a serious bug. If it is a memory leak, this will certainly affect people using Sage, so I don't think we can ignore this so easily.

The increased memory usage is not small either: given that Sage needs about 0.8GB by itself, the extra memory allocated for that test jumped from 0.4GB to 2.2GB.

[vbraun]

comment:93

Thanks to Martin's suggestion, I tracked the memory usage to this doctest:

sage: from sage.crypto.mq.sr import test_consistency
sage: test_consistency(1)  # long time (80s on sage.math, 2011)

[simon-king-jena]

comment:94

Working at #11900, I observe that I get a very massive regression with #10903:

sage: %time for E in cremona_curves([11..100]): S = E.integral_points(both_signs=False)
CPU times: user 54.17 s, sys: 0.49 s, total: 54.66 s
Wall time: 55.38 s

With sage-4.7.2.alpha2 plus #9138 (which causes some regression in other examples), the example only takes 16.48 s, and with #11900 it reduces to 13.22 s.

I am not totally sure that #11339/#10903 are really to blame for it, but it is at least possible.

[83660e46-0051-498b-a8c1-f7a7bd232b5a]

comment:95

In case someone should touch the spkg again, please also fix the Singular script generation in spkg-install by changing $* to "$@".

Do we still need the nanny CFLAGS, overriding a user's settings and forcing -O2 on all platforms except Darwin?

[83660e46-0051-498b-a8c1-f7a7bd232b5a]

comment:96

Replying to @alexanderdreyer:

It seems, that kernel mod_raw.cc lacks the following:

#if defined(ppcMac_darwin)
#define HAVE_ELF_SYSTEM
#endif

I already reported that upstream.

FWIW, it builds on Linux PPC64 (POWER7, SLES 11, GCC 4.4.6), but it currently seems I get more doctest failures than before, i.e. Sage 4.7.2.alpha3 without #11339, the patches from here and the new spkg.

Have to investigate that further.

[vbraun]

comment:97

I found the bug, I had accidentally remove one line too many when I removed some debugging code I introduced in #11339. And that line was the p_Delete in the polynomial destructor...

[vbraun]

one-

[vbraun]

Description changed:

--- 
+++ 
@@ -13,6 +13,6 @@

 * Apply the two dependency patches from #11339

-* **Apply:** [attachment: trac_10903_singular-3-1-3-3.patch](https://github.com/sagemath/sage-prod/files/10652282/trac_10903_singular-3-1-3-3.patch.gz), [attachment: trac_10903_singular-fixes.patch](https://github.com/sagemath/sage-prod/files/10652281/trac_10903_singular-fixes.patch.gz), [attachment: trac_10903_docbuild_fix.patch](https://github.com/sagemath/sage-prod/files/10652285/trac_10903_docbuild_fix.patch.gz), [attachment: trac10903_lgamma_doc.patch](https://github.com/sagemath/sage-prod/files/10652284/trac10903_lgamma_doc.patch.gz)
+* **Apply:** [attachment: trac_10903_singular-3-1-3-3.patch](https://github.com/sagemath/sage-prod/files/10652282/trac_10903_singular-3-1-3-3.patch.gz), [attachment: trac_10903_singular-fixes.patch](https://github.com/sagemath/sage-prod/files/10652281/trac_10903_singular-fixes.patch.gz), [attachment: trac_10903_docbuild_fix.patch](https://github.com/sagemath/sage-prod/files/10652285/trac_10903_docbuild_fix.patch.gz), [attachment: trac10903_lgamma_doc.patch](https://github.com/sagemath/sage-prod/files/10652284/trac10903_lgamma_doc.patch.gz), [attachment: trac_10903_memleak_fix.patch](https://github.com/sagemath/sage-prod/files/10652286/trac_10903_memleak_fix.patch.gz)

[vbraun]

comment:98

Attachment: trac_10903_memleak_fix.patch.gz

[jdemeyer]

Changed work issues from memory usage to none

[jdemeyer]

Description changed:

--- 
+++ 
@@ -13,6 +13,4 @@

 * Apply the two dependency patches from #11339

-* **Apply:** [attachment: trac_10903_singular-3-1-3-3.patch](https://github.com/sagemath/sage-prod/files/10652282/trac_10903_singular-3-1-3-3.patch.gz), [attachment: trac_10903_singular-fixes.patch](https://github.com/sagemath/sage-prod/files/10652281/trac_10903_singular-fixes.patch.gz), [attachment: trac_10903_docbuild_fix.patch](https://github.com/sagemath/sage-prod/files/10652285/trac_10903_docbuild_fix.patch.gz), [attachment: trac10903_lgamma_doc.patch](https://github.com/sagemath/sage-prod/files/10652284/trac10903_lgamma_doc.patch.gz), [attachment: trac_10903_memleak_fix.patch](https://github.com/sagemath/sage-prod/files/10652286/trac_10903_memleak_fix.patch.gz)
-
-
+* **Apply:** [attachment: 10903_flat.patch](https://github.com/sagemath/sage-prod/files/10652287/10903_flat.patch.gz)

[jdemeyer]

comment:99

Testing right now...

[jdemeyer]

All patches together in one patch

[jdemeyer]

comment:100

Attachment: 10903_flat.patch.gz

The memory leak seems to be fixed, so positive_review. Thanks Volker!

I will do some timing tests, also regarding #9138 and #11900. So if I can confirm Simon King's observations, this ticket will need work.

[jdemeyer]

comment:101

As far as I can tell, this does not cause a slowdown, see sage-devel.

[jdemeyer]

Merged: sage-4.7.2.alpha4

[jdemeyer]

comment:103

This fails to build on OS X 10.4 PPC:

Machine:
Darwin moufang.ugent.be 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc
Deleting directories from past builds of previous/current versions of singular-3-1-3-3.p0
Extracting package /Users/jdemeyer/sage-4.7.2.alpha4/spkg/standard/singular-3-1-3-3.p0.spkg ...
-rw-r--r--   1 jdemeyer  jdemeyer  8420878 Oct  4 11:09 /Users/jdemeyer/sage-4.7.2.alpha4/spkg/standard/singular-3-1-3-3.p0.spkg
Finished extraction
****************************************************
Host system
uname -a:
Darwin moufang.ugent.be 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc
****************************************************
****************************************************
CC Version
gcc -v
Using built-in specs.
Target: powerpc-apple-darwin8
Configured with: /private/var/tmp/gcc/gcc-5367.obj~1/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8
Thread model: posix
gcc version 4.0.1 (Apple Computer, Inc. build 5367)
****************************************************
~/sage-4.7.2.alpha4/spkg/build/singular-3-1-3-3.p0/src ~/sage-4.7.2.alpha4/spkg/build/singular-3-1-3-3.p0
patching file factory/assert.h
patching file Singular/configure
~/sage-4.7.2.alpha4/spkg/build/singular-3-1-3-3.p0
make[2]: *** No rule to make target `distclean'.  Stop.
rm: /Users/jdemeyer/sage-4.7.2.alpha4/local/bin/Singular*: No such file or directory
creating cache ./config.cache
checking uname for singular... ppcMac-darwin
checking for gcc... gcc
checking whether the C compiler (gcc  -O3 -g -fPIC ) works... yes
checking whether the C compiler (gcc  -O3 -g -fPIC ) is a cross-compiler... no
[...]
g++ -O3 -g -fPIC -I.. -I/Users/jdemeyer/sage-4.7.2.alpha4/local -pipe -I. -I.. -I/Users/jdemeyer/sage-4.7.2.alpha4/local -I/Users/jdemeyer/sage-4.7.2.alpha4/local/include -I/Users/jdemeyer/sage-4.7.2.alpha4/local/include -I/Users/jdemeyer/sage-4.7.2.alpha4/local/include   -fno-implicit-templates -I.. -I/Users/jdemeyer/sage-4.7.2.alpha4/local -DNDEBUG -DOM_NDEBUG -DppcMac_darwin -DHAVE_CONFIG_H \
  -o Singular \
  tesths.cc iparith.o mpsr_Tok.o claptmpl.o\
  grammar.o scanner.o attrib.o blackbox.o eigenval_ip.o extra.o fehelp.o feOpt.o ipassign.o ipconv.o ipid.o iplib.o ipprint.o ipshell.o newstruct.o lists.o sdb.o fglm.o interpolation.o silink.o ssiLink.o subexpr.o janet.o wrapper.o libparse.o sing_win.o gms.o pcv.o maps_ip.o walk.o walk_ip.o cntrlc.o misc_ip.o calcSVD.o pipeLink.o Minor.o MinorProcessor.o MinorInterface.o bigintm.o pyobject_setup.o bbcone.o bbfan.o denom_list.o minpoly.o  slInit_Static.o mpsr_Put.o mpsr_PutPoly.o mpsr_GetPoly.o mpsr_sl.o mpsr_Get.o mpsr_GetMisc.o mpsr_Error.o  ndbm.o sing_dbm.o -dynamic -L/Users/jdemeyer/sage-4.7.2.alpha4/local/kernel -L../kernel -lkernel -L/Users/jdemeyer/sage-4.7.2.alpha4/local/lib -L/Users/jdemeyer/sage-4.7.2.alpha4/local/lib   -ldl -lm -lsingfac -lsingcf -lntl -lgmp -lreadline -lncurses -lm   -lomalloc_ndebug  ../kernel/mmalloc.o
/usr/bin/ld: warning -L: directory name (/Users/jdemeyer/sage-4.7.2.alpha4/local/kernel) does not exist
/usr/bin/ld: Undefined symbols:
_dynl_close
_dynl_error
_dynl_open
_dynl_sym
collect2: ld returned 1 exit status
make[4]: *** [Singular] Error 1
make[3]: *** [install] Error 1
make[2]: *** [/Users/jdemeyer/sage-4.7.2.alpha4/local/bin/Singular-3-1-3] Error 2

[vbraun]

comment:104

Would that be fixed by Alexander's suggestion in #10903 comment:87

I don't have access to a PPC Mac.

[d46d2cb1-860f-484d-8329-8ebfc9f5d004]

comment:105

Replying to @vbraun:

Would that be fixed by Alexander's suggestion in #10903 comment:87

I think so. Unfortunately I do not have spare time to provida a proper patches spkg :-(

I don't have access to a PPC Mac.

I could test the spkg.

[jdemeyer]

comment:106

Replying to @vbraun:

Would that be fixed by Alexander's suggestion in #10903 comment:87

Yes. Making a new spkg...

[jdemeyer]

Description changed:

--- 
+++ 
@@ -9,7 +9,7 @@

 # Installation instructions

-* **Install:** http://www.stp.dias.ie/~vbraun/Sage/spkg/singular-3-1-3-3.p0.spkg
+* **Install:** [http://boxen.math.washington.edu/home/jdemeyer/spkg/singular-3-1-3-3.p1.spkg](http://boxen.math.washington.edu/home/jdemeyer/spkg/singular-3-1-3-3.p1.spkg)

 * Apply the two dependency patches from #11339

[jdemeyer]

comment:108

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.

[83660e46-0051-498b-a8c1-f7a7bd232b5a]

comment:109

Replying to @vbraun:

Would that be fixed by Alexander's suggestion in #10903 comment:87

Well, smells more as if --without-dynamic-kernel does no longer work... (which we pass on any OS but Linux)

Regarding the ELF fix, cf. this comment...

(I also thought Alexander's fix was already incorporated into the p0 spkg.)

[83660e46-0051-498b-a8c1-f7a7bd232b5a]

comment:110

Replying to @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.

If you don't want to apply the patches in a loop (prepending numbers to [some of] the patches could force the proper order), you should use something like

patch_error()
{
    echo >&2 "Error: Patch failed to apply."
    exit 1
}

...

    patch -p1 < ... || patch_error

...

or use the weirdly-named success() function.

[d46d2cb1-860f-484d-8329-8ebfc9f5d004]

comment:111

Replying to @nexttime:

Well, smells more as if --without-dynamic-kernel does no longer work... (which we pass on any OS but Linux)

Indeed - intended or not - it's still in the spkg.

Regarding the ELF fix, cf. this comment...

It's not that easy: OS X question does not define __ELF__, because it's MACH, not an ELF. Singular just needs an ELF-compatible dlopen here. (So maybe HAVE_ELF_SYSTEM is a misleading macro name.

[d46d2cb1-860f-484d-8329-8ebfc9f5d004]

comment:112

Replying to @nexttime:

Well, smells more as if --without-dynamic-kernel does no longer work... (which we pass on any OS but Linux)

But --with-dl is active. Even thought we do not load parts of the kernel dynamically, we can load other dynamic modules (for instance, there is an experimental python interface for Singular).

[jdemeyer]

comment:113

Replying to @nexttime:

Replying to @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

In any case, I don't see what this has to do with parallel builds.

Can anybody tell me how we should proceed?

[vbraun]

comment:114

Leif wants to be able to grep the install.log for "Error", I think. Thats not particularly high on my agenda, though. Especially since patch will either already fail at the developer's machine or always work (assuming that the hardware is working).

[d46d2cb1-860f-484d-8329-8ebfc9f5d004]

comment:115

Replying to @vbraun:

Leif wants to be able to grep the install.log for "Error", I think. Thats not particularly high on my agenda, though. Especially since patch will either already fail at the developer's machine or always work (assuming that the hardware is working).

BTW: So it's not mandatory anymore to "unroll" patches in the spkg, i.e. to deliver the patched file and use cp? Despite of this, you're right from my point of view.

[d46d2cb1-860f-484d-8329-8ebfc9f5d004]

comment:116

Replying to @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.

The new spkg builds and installs on SuSE 11 amd64 and OS X 10.5 ppc. The tests are running (fine so far). Somebody should test it on Solaris though.

[vbraun]

comment:117

Replying to @alexanderdreyer:

BTW: So it's not mandatory anymore to "unroll" patches in the spkg, i.e. to deliver the patched file and use cp?

Not any more, we have included patch as a standard spkg!

[d46d2cb1-860f-484d-8329-8ebfc9f5d004]

comment:118

Replying to @vbraun:

Not any more, we have included patch as a standard spkg!

Nice!

[83660e46-0051-498b-a8c1-f7a7bd232b5a]

comment:119

Replying to @jdemeyer:

Replying to @nexttime:

Replying to @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++.

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

$ 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".)

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.

[jdemeyer]

comment:120

Replying to @nexttime:

To see what went wrong or which spkgs failed to build / didn't pass the (self-)test suite, one can usually do

$ egrep '^(Error|Failed) ' spkg/logs/*

with variations on -i, -h, -n and -A/B/C... etc.

But every failed spkg also prints the message

sage: An error occurred while installing mpir-2.1.3.p5
Please email sage-devel http://groups.google.com/group/sage-devel
explaining the problem and send the relevant part of
of /home/buildbot/build/sage/iras-1/iras_full/build/sage-4.7.2.alpha4/install.log.  Describe your computer, operating system, etc.
If you want to try to fix the problem yourself, *don't* just cd to
/home/buildbot/build/sage/iras-1/iras_full/build/sage-4.7.2.alpha4/spkg/build/mpir-2.1.3.p5 and type 'make check' or whatever is appropriate.
Instead, the following commands setup all environment variables
correctly and load a subshell for you to debug the error:
(cd '/home/buildbot/build/sage/iras-1/iras_full/build/sage-4.7.2.alpha4/spkg/build/mpir-2.1.3.p5' && '/home/buildbot/build/sage/iras-1/iras_full/build/sage-4.7.2.alpha4/sage' -sh)
When you are done debugging, you can type "exit" to leave the
subshell.

One can easily grep for this to find out which package caused the problem and then look at spkg/logs/$PACKAGENAME.log.

[jdemeyer]

Attachment: singular-3-1-3-3.p0-p1.diff.gz

diff for the new Singular spkg, for review only

[jdemeyer]

comment:121

New spkg with error messages for failed patches: http://boxen.math.washington.edu/home/jdemeyer/spkg/singular-3-1-3-3.p1.spkg. Needs review.

[vbraun]

comment:122

Looks good. I take it from your comment that it works on OSX/PPC. Positive review.

[d46d2cb1-860f-484d-8329-8ebfc9f5d004]

comment:124

Replying to @vbraun:

Looks good. I take it from your comment that it works on OSX/PPC. Positive review.

For the record: I also managed to build, install and succesfully run all tests on SuSE 11.1 SP1 and OSX 10.6 ppc.

[83660e46-0051-498b-a8c1-f7a7bd232b5a]

comment:125

Replying to @vbraun:

Looks good.

Looks better.

Btw., I sometimes also grep for "An error". Grepping for "^(Error|Failed) " (perhaps with context, which doesn't make much sense in the former case) immediately shows you what went wrong. Of course the logs of spkgs that are themselves built in parallel are sometimes harder to read.

[saraedum]

comment:126

trac_10903_singular-fixes.patch seems to remove the functionality of the parameter omit_underscore_names in sageinspect.py's sage_getvariablename(). Was that done on purpose?