Sage 7.5.beta1 released

[Volker Braun]

As always, you can get the latest beta version from the "develop" git branch. Alternatively, the self-contained source tarball is at http://www.sagemath.org/download-latest.html

de71261 Updated SageMath version to 7.5.beta1

a7c0eae Trac #21765: Simplify relative_discriminant() using idealhnf

8bb7f6e Trac #21763: py3 get rid of xrange in matrix folder

98d0f1b Trac #21761: Bug in the Chow ring of a matroid

038e6ad Trac #21759: Fix build of coxeter3

04c1466 Trac #21757: Bug in reflection group to_matrix

1a7daaf Trac #21751: py3 get rid of xrange in polynomials

7de7e32 Trac #21743: Crash when stdin is not a tty

4a5fc58 Trac #21738: %attach has a weird behaviour when dealing with SyntaxError

41e9f60 Trac #21721: Standardize patches in fricas, frobby

614c841 Trac #21658: TestSuite: test that __new__ doesn't crash

9bb5f6f Trac #21651: Segfault in PartitionRefinementLinearCode

a759a04 Trac #21646: Devel manual about docstrings

6614f5f Trac #21606: LatticePoset: Add Alan Day's doubling construction

e130f98 Trac #21082: Prompting about experimental packages: `sage -i -y`, `sage -i -n`

1fb542e Trac #20596: Upgrade to Cython 0.25.1

9cb8eb8 Trac #18843: Differentiable manifolds: vector fields and tensor fields

d6baa17 Trac #21717: Move rational_reconstruction to arith

a59e7e8 Trac #21455: Document that coth et al now work with wildcards

681b779 Trac #21705: Fix GCC warnings in PARI interface

27fa09d Trac #21674: Doctest continuation marked / rings, misc

97b90eb Trac #21652: Uppercasing "seealso"

564b397 Trac #21650: Doctest continuation marker / graphs

dbf9e6e Trac #21648: Doctest continuation marker / matrix

5af76d6 Trac #21599: Work around non-deterministic failure of uncompress on Windows

f10eb6d Trac #21584: Random lattice: element numbering should start from zero

81002f6 Trac #21553: Blacklist PARI's allocatemem method in auto_gen

65ebe8d Trac #21248: Reduce Forms from Stoll and Cremona

94cb16b Trac #21730: Add dedicated symbolic series tests

acff346 Trac #21728: Make Sage run-time dependency of fpylll

bcef947 Trac #21722: Fix build of gap3

4969963 Trac #21715: Update database_cremona_ellcurve

32d4a6c Trac #21710: removing last traces of sagedev from developer manual

a8be7a9 Trac #21706: Fix autotools/texinfo/ncurses problem, change autotools package from experimental to optional

e817d23 Trac #21704: bliss does not support multiple edges

f4ed683 Trac #21699: Change latte_int package type to optional

f9c355e Trac #21698: Change python3 package type to experimental

dfe6b11 Trac #21697: Upgrade pyzmq to version 16.0.0

0ee6abe Trac #21696: fix the use of inline in multiple .pxd files

f91bb46 Trac #21692: fixing jones database optional doctests

45152c9 Trac #21688: Remove non-existing site_packages directory from PYTHONPATH

faa90b2 Trac #21687: Avoid bare "except:" statements

d2aa474 Trac #21685: When building Python on OS X, test whether _scproxy can be imported successfully.

998765a Trac #21684: implement the bhz poset

f6ff4fe Trac #21677: py3 get rid of xrange in various places

c8b7472 Trac #21671: Bug in infinite LS paths crystal operators

8edb138 Trac #21666: Changes to Posets.DivisorLattice()

4b5b572 Trac #21664: Fix initialization of integer and rational vectors

31776e9 Trac #21663: Allow singular_ring_delete(NULL)

915f2a1 Trac #21662: Fix initialization of ComplexIntervalFieldElement

55eac20 Trac #21660: Upgrade MPFR to version 3.1.5

26d4124 Updated SageMath version to 7.5.beta0

[Eric Gourgoulhon]

Build OK + make ptestlong passed on Ubuntu 16.04 x86_64 Xeon E5-2623 + 16 GB RAM.

Eric.

[Dima Pasechnik]

build failure at fpylll due to undeclared dependency on cysignals

(somehow, cygsignals should be built before any cython module; I don't know how this can be enforced without

making it an explicit dependency everywhere)

Dima 

[Jeroen Demeyer]

On 2016-11-02 09:37, Dima Pasechnik wrote:
> build failure at fpylll due to undeclared dependency on cysignals

This is https://trac.sagemath.org/ticket/21795

> somehow, cygsignals should be built before any cython module

The usual "dependencies" files can handle that. Why should cysignals be
treated differently from other dependencies?

[Dima Pasechnik]

I would rather treat cysignals as a part of Python suite, and make sure they are built together with Python

a sort of "codependency" - let's say Python is codependent on cysignals if they are to be built right after Python.

Surely there are more examples like this that can simplify our dependencies graph.

Dima

 

[Jeroen Demeyer]

On 2016-11-02 10:16, Dima Pasechnik wrote:
> I would rather treat cysignals as a part of Python suite, and make sure
> they are built together with Python
> a sort of "codependency" - let's say Python is codependent on cysignals
> if they are to be built right after Python.
> Surely there are more examples like this that can simplify our
> dependencies graph.

-1 because I don't see the point, what is so special about cysignals? It
will only complicate the build system.

[Dima Pasechnik]

My point is that cysignals is essentially a part of the Sage's build system.

Imagine you would need to declare a dependence on python in every package that uses python...

[Jeroen Demeyer]

On 2016-11-02 13:26, Dima Pasechnik wrote:
> My point is that cysignals is essentially a part of the Sage's build system.

No, it's not. It's a package just like numpy or mpfr is a package.

> Imagine you would need to declare a dependence on python in every
> package that uses python...

We actually do that and nobody ever complained about that.

[Ralf Stephan]

Again me with the gcc5 error on OpenSuSE, this time with serial log ;-)

Thanks for any opinion,

[Ralf Stephan]

With this patch it all compiles:

diff --git a/src/sage/libs/singular/decl.pxd b/src/sage/libs/singular/decl.pxd

index 8235e9d..8f355ba 100644

--- a/src/sage/libs/singular/decl.pxd

+++ b/src/sage/libs/singular/decl.pxd

@@ -1,4 +1,4 @@

-# distutils: extra_compile_args = SINGULAR_CFLAGS

+# distutils: extra_compile_args = SINGULAR_CFLAGS -std=c++11

 # distutils: libraries = SINGULAR_LIBRARIES

 # distutils: library_dirs = SINGULAR_LIBDIR

 # distutils: language = c++

diff --git a/src/sage/rings/finite_rings/element_givaro.pxd b/src/sage/rings/finite_rings/element_givaro.pxd

index 91c4ed7..b43f7ad 100644

--- a/src/sage/rings/finite_rings/element_givaro.pxd

+++ b/src/sage/rings/finite_rings/element_givaro.pxd

@@ -1,4 +1,4 @@

-# distutils: extra_compile_args = GIVARO_CFLAGS

+# distutils: extra_compile_args = GIVARO_CFLAGS -std=c++11

 

 from libcpp.vector cimport vector

 ctypedef vector[int] intvec

Is this known? Open ticket with it?

[Volker Braun]

open a ticket

[Ralf Stephan]

https://trac.sagemath.org/ticket/21804

--
You received this message because you are subscribed to the Google Groups "sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-release...@googlegroups.com.
To post to this group, send email to sage-r...@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/d/optout.

[Ralf Stephan]

Hi,

Regardless of the gcc used (Sage internal or not) both git master

and develop crash in make ptestlong in combinat/posets/posets.py.

Crash log is attached.

The crash can be provoked interactively with:

sage:  Poset().is_incomparable_chain_free(1,1)

...

[Emmanuel Charpentier]

On my way towars R 3.3.x, I tried to update my "base Sage". Bad idea... This fails to build flint_2.5.2.p0 : a library fails to build. From the package's log :

/usr/bin/ld: -r and -pie may not be used together
collect2: error: ld returned 1 exit status
../Makefile.subdirs:62: recipe for target '../build/ulong_extras/../ulong_extras.lo' failed

I'll try to recompile in case of the conflicting flags were an effect of parallel build, but I'm not optimistic...

ISTR that a recent upgrade to my system installed a new version of binutils.:

charpent@asus16-ec:/usr/local/sage-7$ dpkg -l "binutils*" | grep ii
ii  binutils                  2.27-9+b1    amd64        GNU assembler, linker and binary utilities
charpent@asus16-ec:/usr/local/sage-7$ ld --version
GNU ld (GNU Binutils for Debian) 2.27
Copyright (C) 2016 Free Software Foundation, Inc.
Ce logiciel est libre; si vous le redistribuez, vous devez le faire selon les termes
de la licence GNU General Public License version 3 ou postérieure selon votre besoin.
Ce logiciel n'est couvert par aucune GARANTIE.

An attempt to compile 7.5beta0 (a week ago) went fine.

Ideas ?

--
Emmanuel Charpentier

[Emmanuel Charpentier]

Second attempt, same problem. This is apparently Trac#21782, which I've upgraded to blocker.

Any suggestion to get unstuck ?

--
Emmanuel Charpentiet

[Dima Pasechnik]

On Saturday, November 5, 2016 at 6:22:22 PM UTC, Emmanuel Charpentier wrote:

Second attempt, same problem. This is apparently Trac#21782, which I've upgraded to blocker.

Any suggestion to get unstuck ?

this: https://groups.google.com/d/msg/sage-devel/TduebNoZuBE/sEULolL0BQAJ

[Francois Bissey]

That was clearly a mistake in flint/arb in the first place. “-r” is a flag
for the linker, not sure what gcc was doing with it in the first place.

Has debian reported upstream?

François

[Dima Pasechnik]

On Saturday, November 5, 2016 at 7:11:29 PM UTC, François wrote:

That was clearly a mistake in flint/arb in the first place. “-r” is a flag
for the linker, not sure what gcc was doing with it in the first place.

Has debian reported upstream?

Flint/arb, you mean? 

I mentioned this to flint people, here is their reaction:

https://groups.google.com/d/msg/flint-devel/Y7v70TW8ABg/slTVZbqyBwAJ

Feel free to talk to them directly. 

[Francois Bissey]

Hum… I was reading the patch in reverse… It changes the correct
form of “-Wl,-r” to “-r”. Probably so that it is ignored by gcc
altogether. That probably generate warnings though.

I can see why gcc complains when -pie is enabled. “-r” is supposed
to create an intermediary shared object that is not to be a library
but to be included in one later on. That probably messes up the “pie”
process.

Strangely enough I don’t have any complaints about flint from
Gentoo hardened which you would expect to have the same problem.
Digging.

François

[Dima Pasechnik]

On Saturday, November 5, 2016 at 10:23:09 PM UTC, François wrote:

Hum… I was reading the patch in reverse… It changes the correct
form of “-Wl,-r” to “-r”. Probably so that it is ignored by gcc
altogether. That probably generate warnings though.

I can see why gcc complains when -pie is enabled. “-r” is supposed
to create an intermediary shared object that is not to be a library
but to be included in one later on. That probably messes up the “pie”
process.

Strangely enough I don’t have any complaints about flint from
Gentoo hardened which you would expect to have the same problem.

I am running Gentoo a laptop since a week or so, and build Sage using

gcc version 4.9.3 (Gentoo 4.9.3 p1.5, pie-0.6.4) just fine.

Not sure it's "harderned" or not.

[Francois Bissey]

Unlikely you are running hardened. To check run:
eselect profile list
If the profile that is selected (with a *) starts with
“hardened” then yes you are using hardened. If not,
you are just normal, like me.

On that ubuntu machine can you post the output of
gcc -dumpspecs
please? I’d like to see if I can spot where they force
“pie”.

François

[Bill Hart]

On 5 November 2016 at 20:11, Francois Bissey <francoi...@canterbury.ac.nz> wrote:

That was clearly a mistake in flint/arb in the first place. “-r” is a flag
for the linker, not sure what gcc was doing with it in the first place.

-Wl is supposed to pass the option to the linker.  

On my machine, Flint doesn't pass any -r to either gcc or the linker, unless you count -Wl, -rpath.

Has debian reported upstream?

Someone reported the issue to us, but we have never heard of PIE, much less do we know what to do about it.

I tried to find out from the debian page for the flint package what changes are necessary to fix the issue, but after going round and round in circles and not finding where this is documented, I gave up.

There should be laws against crippling perfectly working compilers, with severe penalties, up to and including a week without internet access and public shaming by Linus Torvalds.

Bill.

 

François

> To unsubscribe from this group and stop receiving emails from it, send an email to sage-release+unsubscribe@googlegroups.com.

> To post to this group, send email to sage-r...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-release.
> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "sage-release" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sage-release+unsubscribe@googlegroups.com.

[Francois Bissey]

Apologies if you missed my later post. I had read the patch in reverse.
You do the correct thing and they cripple it. In a curious way too.

I suspect they do PIE (position independent executable - a relative of PIC)
wrong.

+1 about having severe penalties for crippling compilers.

François

[Emmanuel Charpentier]

Sorry for being late : I had a severe NMI from the Real World (TM).

Using the patches pointed by Dima succeed in compiling Sage. However, I dat a raft of failutes which mostly relate to pip being outdated.

Updating pip "by hand" (./sage -pip install --upgrade pip) was a bad mistake : different errors at the same point,

I'll (make distclean && make ptestlong ) again  overnight and post the hopefully clean) log tomorrow.

HTH,

PS : about penalties for abusing compilers : did you consider this ?

--
Emmanuel Charpentier

[Michael Orlitzky]

On 11/05/2016 07:19 PM, 'Bill Hart' via sage-release wrote:
>
> Someone reported the issue to us, but we have never heard of PIE, much
> less do we know what to do about it.
>

PIE is like PIC, but for executables. Shared libraries can't rely on
fixed addresses because multiple programs may have the library loaded at
different locations in memory. So, you want to build the libraries
"position-independent" -- that's PIC.

Executables don't have the same requirement, but if you can randomize
the address space of your executables, it makes them a lot harder to
exploit. That general idea falls under the acronym ASLR, and
position-independent executables (PIE) are becoming mainstream because
they facilitate ASLR.

[Bill Hart]

Thanks for the explanation. For a while we thought ASLR was the cause of erratic timings we were experiencing on one of our machines. But it turns out someone had already switched it off, which probably illustrates how much we value all this "hardening".

I do think it is working though. Everything seems much harder now.

Bill. 

[Ralf Stephan]

This is now:

https://trac.sagemath.org/ticket/21828

--
You received this message because you are subscribed to the Google Groups "sage-release" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sage-release...@googlegroups.com.

[Emmanuel Charpentier]

A second attempt at rebuilding after distcleant gives the same results : a raft of errors mostly bound to pip's advertising. However, I an not sure of what I read in the results of tolerance.py...

I'll re-upgrade pip and post the results.

HTH,

--
Emmanuel Charpentier

[Emmanuel Charpentier]

After manually upgrading pip, I still get a raft of failed test. It seems (see uploaded log) that those are due to pip advertising a deprecation of teh format used for the database.

One errot (on simplicial_complex.py) is genuine ; this test appasses with no errors when run standalone (a long standing problem with this test.

I conclude that :
    - the patches pointed by Dima do solve the problem of compiling flint and arb on Debian testing
    - another problem is introduced by pip advertising.

Questions :
    - Should I package the patches that solve Trac#21782
    - Should I create a new ticket about  pip's newfound verbosity ?

HTH,

--
Emmanuel Charpentier

[Francois Bissey]

I don’t like the debian fix. In fact it doesn’t look like a fix at all.
I would need a serious explanation of their change.
That “-Wl,-r” already caused trouble in spack last month (on OS X) and as it
turns out it was spack's compiler wrappers’ fault. I am inclined to say
that debian did something nasty or not well thought about to gcc.

Which feels rather improbable on the part of debian but we never know.

François

> --
> You received this message because you are subscribed to the Google Groups "sage-release" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to sage-release...@googlegroups.com.

> To post to this group, send email to sage-r...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-release.
> For more options, visit https://groups.google.com/d/optout.

> <ptestlong.log>

[Francois Bissey]

I should be a bit more specific about why I don’t think it is a
real “fix”.
It works for the new pie enforcing debian version of gcc. We can put
that as a fact. It does so by replacing “-Wl,-r” by “-r”, so instead
of passing “-r” to the linker, gcc is now using a “-r” option directly
that passes the right magic to the linker presumably.

Presumably because I don’t have any documentation about “-r” in the version
of gcc 5.4.0 I have installed here.

So, is this a new gcc 6+ option, an undocumented option or a specific
option of that debian compiler? In 2 out of 3 cases that means adopting
the debian fix will break on other compiler/distro.

Which may be why they didn’t follow it up to upstream flint/arb. It is a
debian specific patch. If this is the case the fix can only be applied
conditionally.

I may be poking myself in the eye here but I think just adopting the patch
is risky.

François

[Emmanuel Charpentier]

Dear François,

Le dimanche 6 novembre 2016 12:09:51 UTC+1, François a écrit :

I should be a bit more specific about why I don’t think it is a
real “fix”.
It works for the new pie enforcing debian version of gcc. We can put
that as a fact. It does so by replacing “-Wl,-r” by “-r”, so instead
of passing “-r” to the linker, gcc is now using a “-r” option directly
that passes the right magic to the linker presumably.

Presumably because I don’t have any documentation about “-r” in the version
of gcc 5.4.0 I have installed here.

Neither do I perusing gcc 6.2.0 doc...

So, is this a new gcc 6+ option, an undocumented option or a specific
option of that debian compiler? In 2 out of 3 cases that means adopting
the debian fix will break on other compiler/distro.

Which may be why they didn’t follow it up to upstream flint/arb. It is a
debian specific patch. If this is the case the fix can only be applied
conditionally.

Which involves a bit of black magic in autotools configuration files I do not (yet) know how to do.

I may be poking myself in the eye here but I think just adopting the patch
is risky.

Could we try the "Great White Shark" methof (i. e. bite and see what happens) ?  You could try compiling flint/arb with this patch with your gcc 5.4.x you say you have installed and report back the ravages...

HTH,

--
Emmanuel Charpentier

[John H Palmieri]

Is your pip issue fixed by https://trac.sagemath.org/ticket/21812?

[Emmanuel Charpentier]

I dunno yet, just testing in a branch with 21812 and the Debian fix for flint François doesn't like. It'll have to wait a bit (ReaLife NMI...).

Posting results in 2-4 hours. Stay tuned.

--
Emmanuel Charpentier

[Emmanuel Charpentier]

Le dimanche 6 novembre 2016 17:04:37 UTC+1, John H Palmieri a écrit :

Is your pip issue fixed by https://trac.sagemath.org/ticket/21812?

Nope : with an updated pip, I get the deprecation warnings that plagued my third attempt (see enclosed log).

I'll try to distclean and retest, to test it against pi^8.x. Need a couple of hours for that.

HTH,

--
Emmanuel Charpentier

[François Bissey]

On 07/11/16 02:21, Emmanuel Charpentier wrote:
> Could we try the "Great White Shark" methof (i. e. bite and see what
> happens) ? You could try compiling flint/arb with this patch with your
> gcc 5.4.x you say you have installed and report back the ravages...

Can do that. I'll just grab pop corn first - just in case.

Francois

[Emmanuel Charpentier]

After distclean (in order to retrieve a system witp pip 8.x), Singular des not build (see enclosed (parallel) install and pkg logs).

distclean and serial rebuild ( unset MAKE && make distclean && make && export MAKE="make -j8" && make ptestlong ) underway (that will be overnight, don't hold your breath...).

HTH,

--
Emmanuel Charpentier

[John H Palmieri]

On OS X 10.12, I get an intermittent failure with matrix_integer_dense.pyx. The end of the failure:

sage: A = random_matrix(ZZ, 4, 4) ## line 4266 ##
sage: B = random_matrix(ZZ, 2, 3) ## line 4267 ##
sage: B._solve_flint(A) ## line 4268 ##
sage: A._solve_flint(B, right=False) ## line 4272 ##
sage: A._solve_flint(B, right=True) ## line 4276 ##
sage: A = random_matrix(ZZ, 2000, 2000) ## line 4283 ##
sage: B = random_matrix(ZZ, 2000, 2000) ## line 4284 ##
sage: t0 = walltime() ## line 4285 ##
sage: alarm(2); A._solve_flint(B)  # long time ## line 4286 ##
sage: t = walltime(t0) ## line 4290 ##
sage: t < 10 or t ## line 4291 ##
True
sage: sig_on_count() # check sig_on/off pairings (virtual doctest) ## line 4297 ##
0
sage: t = ModularSymbols(11,sign=1).hecke_matrix(2) ## line 4546 ##
------------------------------------------------------------------------
0   signals.so                          0x0000000109732005 print_backtrace + 37
------------------------------------------------------------------------
Unhandled SIGSEGV: A segmentation fault occurred.
This probably occurred because a *compiled* module has a bug
in it and is not properly wrapped with sig_on(), sig_off().
Python will now terminate.

If I run the test 10 times (with "sage -t --long --global-iterations=10 src/sage/matrix/matrix_integer_dense.pyx", I typically get 1 failure, sometimes 2, sometimes 0. Has anyone else seen this?

  John

[François Bissey]

On 07/11/16 11:37, Emmanuel Charpentier wrote:
> Singular des not build (see enclosed (parallel) install and pkg logs).

Nothing that further clean up in spkg-install wouldn't fix but it
shouldn't happen from a distclean state since the offending file
should have been removed:
/usr/bin/install: cannot create regular file
'/usr/local/sage-7/local/include/omalloc/mylimits.h': File exists
Makefile:1114: recipe for target
'install-nodist_libomalloc_includeHEADERS' failed

Does it happen to have funny permissions?

Francois

[François Bissey]

Debian had a lot of failures in their *7.4* build
from matrix_integer_dense too. I cannot guarantee that was
the exact same one. But https://trac.sagemath.org/ticket/21749
fixed their problems.

Francois

> --
> You received this message because you are subscribed to the Google
> Groups "sage-release" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to sage-release...@googlegroups.com

> <mailto:sage-release...@googlegroups.com>.

> To post to this group, send email to sage-r...@googlegroups.com

> <mailto:sage-r...@googlegroups.com>.

[Emmanuel Charpentier]

Can't tell : the disclean starting my serial build attempt (underway)
got rid of all $SAGE_ROOT/local/include/omalloc, apparently...

Sorry,

--
Emmanuel Charpentier

>
> Francois
>

[François Bissey]

Well that was interesting! It appears that we have something
that is undocumented. It worked without complaining with
* gcc 5.4.0 on my Gentoo box
* gcc 4.9.3 from sage on OS X
* more surprising: clang on OS X (10.12)

Francois

[Emmanuel Charpentier]

Well, a serial recompilation with pip 8.x works (see enclosed logs).

So, the proposed solution to Trac#21812 seems hardly acceptable (working only for a serial build with an outmoded pip). I'll mark it as "needs_work".

Would it be problematic to upgrade pip ?

HTH,

--
Emmanuel Charpentier

[Jeroen Demeyer]

On 2016-11-07 08:31, Emmanuel Charpentier wrote:
> Well, a serial recompilation with pip 8.x works (see enclosed logs).

That test failure is #15585 which is totally unrelated to pip.

[Emmanuel Charpentier]

The transient failure on simplicial_complex.py doesn't worry me : it failed to reproduce when run standalone every time I found it.

My beef is with the raft of test failures due to pip's advertising we are seeing since pip 9.0.0 is out. Please see this thread starting with this post, and read the logs I've attached. The reported failures are all (but simplicial_complex's transient failure) due to pip's advertising.

• With the original pip and no patch : this gives test failures due to pip advertising its new version..
• With the original pip and your patch ; success with serial buikld, but fails to build if parallel build.
• With an updated pip (wityh and without your patch) : test failures due to pip complaining about a deprecated format.

Hardly satisfying... That's why I positioned "needs work" in the ticket page.

And I still think that this ticket is not yet ready for merging, unless you explain *why* it is enough. But I've not (yet) repositioned "needs_work" in the ticket's page.

HTH,

--
Emmanuel Charpentier

[Jeroen Demeyer]

On 2016-11-07 11:43, Emmanuel Charpentier wrote:
> and read the logs I've attached.

It's a long thread with many posts of you, I am getting lost. Can you
please reboot the discussion at #21812? And attach a log file showing
why you think that #21812 does not work.

[Emmanuel Charpentier]

Done, but not inTrac#21812, which has been closed by Volker. I created 21835 instead.

HTH,

--
Emmanuel Charpentier

[John H Palmieri]

I applied #21749, but it didn't help.

  John

[Francois Bissey]

OK I will have to give it a try on my laptop. It will be a few hours before
I can report something.

François

> --
> You received this message because you are subscribed to the Google Groups "sage-release" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to sage-release...@googlegroups.com.
> To post to this group, send email to sage-r...@googlegroups.com.

[Francois Bissey]

Doctests interrupted: 1/1 files tested
sage -t --long --warn-long 51.1 src/sage/matrix/matrix_integer_dense.pyx # Killed due to segmentation fault
Doctests interrupted: 2/1 files tested
Doctests interrupted: 3/1 files tested
Doctests interrupted: 4/1 files tested
Doctests interrupted: 5/1 files tested
Doctests interrupted: 6/1 files tested
Doctests interrupted: 7/1 files tested
sage -t --long --warn-long 51.1 src/sage/matrix/matrix_integer_dense.pyx # Killed due to bus error
Doctests interrupted: 8/1 files tested
Doctests interrupted: 9/1 files tested

So definitely something going on there, on Sierra with the latest Xcode (8.1).

François

[Emmanuel Charpentier]

I added the original author's name to the patches and in the ticket. Therefore, Trac#21782 awaits review.el

--
Emmanuel Charpentier