Sage 8.7.beta6 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

c59b6881d8 (tag: 8.7.beta6, trac/develop) Updated SageMath version to 8.7.beta6

1410d220ab Trac #27379: Speed up coercions

93923a826c Trac #27001: py3: fix pip_installed_packages

6f4efa962a Trac #27381: Use of -valgrind/--valgrind in doctesting is broken

579dcfca6c Trac #27378: Py3: Fix graphic_matroids.py for python3

59c9d07b0e Trac #27371: coxeter_diagram() of relabeled Cartan types should attempt to relabel their base Coxeter diagram

c79e04f661 Trac #27362: Setting PYTHONPATH in spkg-install for pip is fragile

20c3d7a1b8 Trac #27238: use system's gf2x if available

5717cdd07d Trac #25614: 2 internet doctest failing in misc/persist.pyx

0218ccfee5 Trac #23024: Replacement of sage/libs/ppl.pyx by pplpy

b5905c6bd7 Trac #27380: fix gap_packages install on OSX

3985cf3666 Trac #27361: MR8: fix doctest for an undated sequence

f8252a7ded Trac #27353: Coerce_dict deprecations and documention updates

dc7b849a5c Trac #27349: py3 compatible test for the category of finite posets

05319047a1 Trac #27357: remove deprecation in finite state machines

eba7d0f3c4 Trac #27356: remove one deprecated file in species

2419827a91 Trac #27355: remove deprecated stuff in pbori.pyx

9f32d7ee13 Trac #27344: py3: fix some doctests about hash for real and complex double

ce983fe476 Trac #27342: py3: some tiny fixes in numerical folder

d526ff1cf0 Trac #27245: py3: fix doctests in generic_graph (part 9) -- automorphism_group

bbea55c96e Trac #27335: Out-of-bounds memory access in PARI isprime() function

b58cc78594 Trac #27267: Segfaults in cypari2 when running out of stack during deep object deallocation

4ab5e8ed62 Trac #27345: details in quasisymmetric functions

cea95db339 Trac #27343: py3: various tiny fixes

22b485e035 Trac #27340: Update git-trac instructions in developer's guide

5fb4d426a2 Trac #27179: py3: fix doctest in generic_graph (part 2) -- cycle_basis

613a369840 Trac #27065: py3: handle the explain_pickle problem

bf8228587a Trac #27332: py3: Fix printing of microseconds in timeit

7422882f6c Trac #27329: Polyhedron/base: very minor "fixes"

2d21b7cbfc Trac #27322: Fix indentation in 'solve' docstring

5fc7c83a15 Trac #27338: Fix Trac reference in doctest for ticket 15669

bd7dbaa092 Trac #27337: Deprecate imports in sage.tests.all: no need to important into global namespace

94d773a9db Trac #10599: implicit_plot3d should be able to handle functions with AlgebraicNumber values

2b366fa439 Trac #27341: spring cleanup in Hasse diagrams

34a9911ffb Trac #27256: Re-enable USE_TLS=1 when building OpenBLAS SPKG

217cb83113 (tag: 8.7.beta5) Updated SageMath version to 8.7.beta5

[Emmanuel Charpentier]

On Debian testing running on core i7 + 16 GB RAM, incremental build (Python 2.7) starting from 8.7.beta5 builds and passes ptestlong with no failure.

HTH,

[Sébastien Labbé]

Testing with --optional=sage,optional,external

with

Using --optional=bliss,cbc,ccache,cmake,cryptominisat,dot2tex,external,glucose,lrslib,memlimit,mpir,normaliz,notedown,pandoc_attributes,pycosat,pynormaliz,python2,rst2ipynb,sage

External software detected for doctesting: ffmpeg,graphviz,gurobi,imagemagick,internet,latex,pandoc

I get All tests passed except:

----------------------------------------------------------------------

sage -t --long src/sage/symbolic/integration/external.py  # 1 doctest failed
sage -t --long src/sage/arith/misc.py  # 1 doctest failed
sage -t --long src/sage/combinat/designs/ext_rep.py  # 1 doctest failed
sage -t --long src/sage/combinat/designs/design_catalog.py  # 3 doctests failed
sage -t --long src/sage/combinat/designs/covering_design.py  # 2 doctests failed
----------------------------------------------------------------------

misc.py and external.py issues are not reproducable:

sage -t src/sage/arith/misc.py
    [918 tests, 4.20 s]
sage -t src/sage/symbolic/integration/external.py
    [35 tests, 22.79 s]

designs failures seem related to a URL that changed again.

[Emmanuel Charpentier]

Ditto on two other similar achines; however, I got a transient failure on tesing an example coming form the "Mathematical Computihg with Sagemath" book :

----------------------------------------------------------------------

sage -t --long --warn-long 53.4 src/sage/tests/books/computational-mathematics-with-sagemath/graphique_doctest.py  # 1 doctest failed

----------------------------------------------------------------------

The relevant portion of the log is :

File "src/sage/tests/books/computational-mathematics-with-sagemath/graphique_doctest.py", line 112, in sage.tests.books.computational-mathematics-with-sagemath.graphique_doctest

Failed example:

    for i in srange(-2, 2, 0.2):  # long time

        g += line(desolve_rk4(DE, y(x), ics=[1, i],\

                          step=0.05, end_points=[0,2]))

        g += line(desolve_rk4(DE, y(x), ics=[-1, i],\

                          step=0.05, end_points=[-2,0]))

Exception raised:

    Traceback (most recent call last):

      File "/usr/local/sage-8/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 671, in _run

        self.compile_and_execute(example, compiler, test.globs)

      File "/usr/local/sage-8/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 1095, in compile_and_execute

        exec(compiled, globs)

      File "<doctest sage.tests.books.computational-mathematics-with-sagemath.graphique_doctest[50]>", line 3, in <module>

        step=RealNumber('0.05'), end_points=[Integer(0),Integer(2)]))

      File "/usr/local/sage-8/local/lib/python2.7/site-packages/sage/calculus/desolvers.py", line 1378, in desolve_rk4

        sol_2=maxima(cmd).sage()

      File "/usr/local/sage-8/local/lib/python2.7/site-packages/sage/interfaces/interface.py", line 1074, in sage

        return self._sage_(*args, **kwds)

      File "/usr/local/sage-8/local/lib/python2.7/site-packages/sage/interfaces/maxima_abstract.py", line 1238, in _sage_

        maxima=self.parent())

      File "/usr/local/sage-8/local/lib/python2.7/site-packages/sage/calculus/calculus.py", line 2210, in symbolic_expression_from_maxima_string

        raise TypeError("unable to make sense of Maxima expression '%s' in Sage"%s)

    TypeError: unable to make sense of Maxima expression '(kill(sage4)$o44)[[1.0,-2.0],[1.05,-2.149874965475482],[1.1,-2.298999939830521],[1.15,-2.446624921487998],[1.2,-2.591999909207452],[1.25,-2.7343749020044],[1.3,-2.872999899091065],[1.35,-3.007124899832311],[1.4,-3.135999903712506],[1.45,-3.258874910310362],[1.5,-3.374999919279643],[1.55,-3.483624930334245],[1.6,-3.58399994323656],[1.65,-3.675374957788335],[1.7,-3.756999973823437],[1.75,-3.828124991202094],[1.8,-3.888000009806273],[1.85,-3.935875029535953],[1.9,-3.971000050306113],[1.95,-3.992625072044261],[2.0,-4.000000094688424]]' in Sage

**********************************************************************

1 item had failures:

   1 of 117 in sage.tests.books.computational-mathematics-with-sagemath.graphique_doctest

In all cases, re-running the doctest standalone passed.

HTH,

[kcrisman]

upgrading from some early 8.6 beta, I get something weird with file permissions on gap.  Everything seems to go well, but:

pkg/laguna-3.9.0 -> /Users/.../sage/local/var/tmp/sage/build/gap-4.10.0.p0/inst/Users/.../sage/local/share/gap/pkg

pkg/polenta-1.3.8 -> /Users/.../sage/local/var/tmp/sage/build/gap-4.10.0.p0/inst/Users/.../sage/local/share/gap/pkg

pkg/polycyclic-2.14 -> /Users/.../sage/local/var/tmp/sage/build/gap-4.10.0.p0/inst/Users/.../sage/local/share/gap/pkg

pkg/resclasses-4.7.1 -> /Users/.../sage/local/var/tmp/sage/build/gap-4.10.0.p0/inst/Users/.../sage/local/share/gap/pkg

pkg/sophus-1.24 -> /Users/.../sage/local/var/tmp/sage/build/gap-4.10.0.p0/inst/Users/.../sage/local/share/gap/pkg

pkg/tomlib-1.2.7 -> /Users/.../sage/local/var/tmp/sage/build/gap-4.10.0.p0/inst/Users/.../sage/local/share/gap/pkg

../gap -> /Users/.../sage/local/var/tmp/sage/build/gap-4.10.0.p0/inst/Users/.../sage/local/bin/gap

real 2m48.230s

user 1m30.082s

sys 0m59.461s

Copying package files from temporary location /Users/.../sage/local/var/tmp/sage/build/gap-4.10.0.p0/inst to /Users/.../sage/local

cp: cannot overwrite directory /Users/.../sage/local/./share/gap/bin/x86_64-apple-darwin15.6.0-default64/src with non-directory /Users/.../sage/local/var/tmp/sage/build/gap-4.10.0.p0/inst/Users/.../sage/local/./share/gap/bin/x86_64-apple-darwin15.6.0-default64/src

cp: /Users/.../sage/local/./share/gap/pkg/ctbllib/tst/docxpl.tst: Permission denied

************************************************************************

Error copying files for gap-4.10.0.p0.

************************************************************************

I have a feeling that there is a typo of some kind in the commit 

https://github.com/sagemath/sage/commit/ca94bd97d73ee544c273fbb28cb774b3af12ecb6#diff-a9a04fa360dca60daa488241916fdb9c

though I can't say immediately where, because the full line is

non-directory /Users/karl.crisman/Downloads/sage/local/var/tmp/sage/build/gap-4.10.0.p0/inst/Users/karl.crisman/Downloads/sage/local/./share/gap/bin/x86_64-apple-darwin15.6.0-default64/src

and indeed I don't see why there should be a file that has the entire path to sage/local TWICE; probably should use a temp file if for some reason that was the desired behavior? I did not do anything unusual in this setup.

Thanks!  Everything else seems to be progressing normally.

[Steven Trogdon]

Perhaps this is https://trac.sagemath.org/ticket/26996#comment:23. Or at least very similar.

[Dima Pasechnik]

https://trac.sagemath.org/ticket/27388 fixed the permissions, but
because it's an upgrade from the state where there was a read-only
file, it breaks (on OSX only)

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

[kcrisman]

On Friday, March 8, 2019 at 3:24:45 AM UTC-5, Dima Pasechnik wrote:

https://trac.sagemath.org/ticket/27388 fixed the permissions, but
because it's an upgrade from the state where there was a read-only
file, it breaks (on OSX only)

Would that mean that, in general, upgrades from beta4 (which seems to be the last version without this problem, according to one of the tickets) via git pull and make will break indefinitely?  Should we have a blanket recommendation to rebuild from scratch?  Thanks for any advice here - luckily from testing the app version I have some still working Sage installs, but I like having my devel version separately working.

[Dima Pasechnik]

On Fri, Mar 8, 2019 at 12:40 PM kcrisman <kcri...@gmail.com> wrote:
>
>
>
> On Friday, March 8, 2019 at 3:24:45 AM UTC-5, Dima Pasechnik wrote:
>>
>> https://trac.sagemath.org/ticket/27388 fixed the permissions, but
>> because it's an upgrade from the state where there was a read-only
>> file, it breaks (on OSX only)
>
>
> Would that mean that, in general, upgrades from beta4 (which seems to be the last version without this problem, according to one of the tickets) via git pull and make will break indefinitely? Should we have a blanket recommendation to rebuild from scratch?

this is too blanket :-)
e.g. in this particular case it suffices to manually remove SAGE_LOCAL/share/gap
and rebuild gap spkg
(and then run make, naturally...)

Certainly there is never a guarantee that a "git pull"+"make" would
just work, as
the current state could be beyond repair...

> Thanks for any advice here - luckily from testing the app version I have some still working Sage installs, but I like having my devel version separately working.
>

[kcrisman]

this is too blanket :-)
e.g. in this particular case it suffices to manually remove SAGE_LOCAL/share/gap
and rebuild gap spkg
(and then run make, naturally...)

Great, thanks!  Apparently that sufficed.

 

Certainly there is never a guarantee that a "git pull"+"make" would
just work, as
the current state could be beyond repair...

Yes, of course!  In this case I had a working Sage install at beta1 or beta2, though.

[kcrisman]

On Friday, March 8, 2019 at 8:18:02 AM UTC-5, Dima Pasechnik wrote:

On Fri, Mar 8, 2019 at 12:40 PM kcrisman <kcri...@gmail.com> wrote:
>
>
>
> On Friday, March 8, 2019 at 3:24:45 AM UTC-5, Dima Pasechnik wrote:
>>
>> https://trac.sagemath.org/ticket/27388 fixed the permissions, but
>> because it's an upgrade from the state where there was a read-only
>> file, it breaks (on OSX only)
>
>
> Would that mean that, in general, upgrades from beta4 (which seems to be the last version without this problem, according to one of the tickets) via git pull and make will break indefinitely?  Should we have a blanket recommendation to rebuild from scratch?

this is too blanket :-)
e.g. in this particular case it suffices to manually remove SAGE_LOCAL/share/gap
and rebuild gap spkg
(and then run make, naturally...)

Weirdly, I had to do this again even after the update mentioned here (apparently going from 8.7.beta6 to 8.9.beta6).   Is this likely to happen every time we upgrade GAP?

[Dima Pasechnik]

this is a MacOS only bug. Someone running it should work on fix...

--

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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-release/a06cf450-3b21-44de-be6b-b870dd27d64a%40googlegroups.com.

[E. Madison Bray]

On Thu, Mar 7, 2019 at 5:50 PM kcrisman <kcri...@gmail.com> wrote:
>
> upgrading from some early 8.6 beta, I get something weird with file permissions on gap. Everything seems to go well, but:
>
>
>
> pkg/laguna-3.9.0 -> /Users/.../sage/local/var/tmp/sage/build/gap-4.10.0.p0/inst/Users/.../sage/local/share/gap/pkg
>
> pkg/polenta-1.3.8 -> /Users/.../sage/local/var/tmp/sage/build/gap-4.10.0.p0/inst/Users/.../sage/local/share/gap/pkg
>
> pkg/polycyclic-2.14 -> /Users/.../sage/local/var/tmp/sage/build/gap-4.10.0.p0/inst/Users/.../sage/local/share/gap/pkg
>
> pkg/resclasses-4.7.1 -> /Users/.../sage/local/var/tmp/sage/build/gap-4.10.0.p0/inst/Users/.../sage/local/share/gap/pkg
>
> pkg/sophus-1.24 -> /Users/.../sage/local/var/tmp/sage/build/gap-4.10.0.p0/inst/Users/.../sage/local/share/gap/pkg
>
> pkg/tomlib-1.2.7 -> /Users/.../sage/local/var/tmp/sage/build/gap-4.10.0.p0/inst/Users/.../sage/local/share/gap/pkg
>
> ../gap -> /Users/.../sage/local/var/tmp/sage/build/gap-4.10.0.p0/inst/Users/.../sage/local/bin/gap
>
>
> real 2m48.230s
>
> user 1m30.082s
>
> sys 0m59.461s
>
> Copying package files from temporary location /Users/.../sage/local/var/tmp/sage/build/gap-4.10.0.p0/inst to /Users/.../sage/local
>
> cp: cannot overwrite directory /Users/.../sage/local/./share/gap/bin/x86_64-apple-darwin15.6.0-default64/src with non-directory /Users/.../sage/local/var/tmp/sage/build/gap-4.10.0.p0/inst/Users/.../sage/local/./share/gap/bin/x86_64-apple-darwin15.6.0-default64/src
>
> cp: /Users/.../sage/local/./share/gap/pkg/ctbllib/tst/docxpl.tst: Permission denied
>
> ************************************************************************
>
> Error copying files for gap-4.10.0.p0.
>
> ************************************************************************
>
>
> I have a feeling that there is a typo of some kind in the commit
>
>
> https://github.com/sagemath/sage/commit/ca94bd97d73ee544c273fbb28cb774b3af12ecb6#diff-a9a04fa360dca60daa488241916fdb9c

I don't think so but...

> though I can't say immediately where, because the full line is
>
>
> non-directory /Users/karl.crisman/Downloads/sage/local/var/tmp/sage/build/gap-4.10.0.p0/inst/Users/karl.crisman/Downloads/sage/local/./share/gap/bin/x86_64-apple-darwin15.6.0-default64/src
>
>
> and indeed I don't see why there should be a file that has the entire path to sage/local TWICE; probably should use a temp file if for some reason that was the desired behavior? I did not do anything unusual in this setup.

That's expected. The package build directory is under SAGE_LOCAL
($SAGE_LOCAL/var/tmp/sage/build/gap-4.10.0.p0) but the file's
destination path ($SAGE_LOCAL) is appended to this. This is how it's
supposed to work (DESTDIR installation).

It's probably too late to diagnose now (though it would be good if you
could give steps to reproduce). But the question is what type of file
was

/Users/karl.crisman/Downloads/sage/local/./share/gap/bin/x86_64-apple-darwin15.6.0-default64/src

that it refuses to overwrite because it was supposedly a directory?

The GAP package installs a *symlink* at the path
$SAGE_LOCAL/share/gap/bin/<platform-triplet>/src

When you upgrade GAP, first of all, it should be *uninstalling* the
previous gap package, so this link should just be removed. The
question is was it a symlink for you in the first place? Or an actual
directory? When you run `make clean-gap` does it get removed?

I think normally there hasn't been a problem with this, at least not
with consistent incremental updates, or else it would show up on the
patchbot.

In other words, I don't think you'll see this every time your gap
package updates. But if you do that would be worth knowing about and
investigating.

[kcrisman]

That's expected.  The package build directory is under SAGE_LOCAL
($SAGE_LOCAL/var/tmp/sage/build/gap-4.10.0.p0) but the file's
destination path ($SAGE_LOCAL) is appended to this.  This is how it's
supposed to work (DESTDIR installation).

It's probably too late to diagnose now (though it would be good if you
could give steps to reproduce).

Yeah, unfortunately my main goal was getting a working Sage install, so the evidence has been eliminated, so to speak.

 

 But the question is what type of file
was

/Users/karl.crisman/Downloads/sage/local/./share/gap/bin/x86_64-apple-darwin15.6.0-default64/src

that it refuses to overwrite because it was supposedly a directory?

I can tell you a rough answer to that, after my most recent upgrade the name of the directory seems to have changed slightly though:

$ ls -l ~/Downloads/sage/local/share/gap/bin/x86_64-apple-darwin15.6.0-default64-kv3/

total 32

lrwxr-xr-x  1 karl.crisman  78570554  18 Aug 14 14:39 config.h -> ../../gen/config.h

lrwxr-xr-x  1 karl.crisman  78570554   9 Aug 14 14:39 gac -> ../../gac

lrwxr-xr-x  1 karl.crisman  78570554   9 Aug 14 14:39 gap -> ../../gap

lrwxr-xr-x  1 karl.crisman  78570554   9 Aug 14 14:40 src -> ../../src

 

The GAP package installs a *symlink* at the path
$SAGE_LOCAL/share/gap/bin/<platform-triplet>/src

So yes, that is what seems to be happening.

 

When you upgrade GAP, first of all, it should be *uninstalling* the
previous gap package, so this link should just be removed.  The
question is was it a symlink for you in the first place?

Apparently.

 

 Or an actual
directory?  When you run `make clean-gap` does it get removed?

Is that something I can do from within Sage?  I didn't know that was a make target for us.   My assumption is that the symlink was not removed or it wouldn't have complained.

[E. Madison Bray]

There was a bug fixed just a few months ago related to this:
https://trac.sagemath.org/ticket/27589

Symbolic links were not being removed properly. They should be now,
though. It's possible just from an older install something was left
behind. Who knows...

>> Or an actual
>> directory? When you run `make clean-gap` does it get removed?
>>
>
> Is that something I can do from within Sage? I didn't know that was a make target for us. My assumption is that the symlink was not removed or it wouldn't have complained.

My mistake, that should be `make gap-clean`. But yes, you can do that
from the base of SAGE_ROOT. This also happens when you force
re-isinstall a package as with `./sage -f gap`.

[Markus Wageringel]

This also happened to me a few weeks ago. The underlying problem seems to be that the uninstall script fails because it tries to call sage-dist-helpers, but cannot find it. This file has recently been moved from src/bin to build/bin, which the uninstall script cannot know about. Once upgraded to Gap 4.10.2.p0, it points to the new location of sage-dist-helpers, so this particular problem should not happen again.

This has also been reported on devel [1,2] and might affect more Mac users when upgrading to 8.9. Perhaps a copy of sage-dist-helpers could be added back to src/bin for some deprecation period?

[1] https://groups.google.com/forum/#!topic/sage-devel/cdw793St6cE

[2] https://groups.google.com/forum/#!topic/sage-devel/h-hXvO2fxgc

[John H Palmieri]

Yes, that fits. Now that I know to look, I see buried in my gap install log

Uninstalling existing 'gap'
Running pre-uninstall script for 'gap'
/Users/jpalmier/Desktop/Sage/git/sage/local/var/lib/sage/scripts/gap/spkg-prerm: line 13: /Users/jpalmier/Desktop/Sage/git/sage/src/bin/sage-dist-helpers: No such file or directory
Error: failed to source sage-dist-helpers
Is /Users/jpalmier/Desktop/Sage/git/sage the correct SAGE_ROOT?
Error: The pre-uninstall script for 'gap' failed; the package will not be uninstalled, and some manual intervention may be needed to repair the package's state before uninstallation can proceed.  Check further up in this log for more details, or the pre-uninstall script itself at /Users/jpalmier/Desktop/Sage/git/sage/local/var/lib/sage/scripts/gap/spkg-prerm.

[E. Madison Bray]

On Thu, Aug 15, 2019 at 6:58 PM Markus Wageringel
<markus.w...@gmail.com> wrote:
>
> This also happened to me a few weeks ago. The underlying problem seems to be that the uninstall script fails because it tries to call sage-dist-helpers, but cannot find it. This file has recently been moved from src/bin to build/bin, which the uninstall script cannot know about. Once upgraded to Gap 4.10.2.p0, it points to the new location of sage-dist-helpers, so this particular problem should not happen again.

Good catch!

> This has also been reported on devel [1,2] and might affect more Mac users when upgrading to 8.9. Perhaps a copy of sage-dist-helpers could be added back to src/bin for some deprecation period?

A symlink could do it.

[kcrisman]

> This has also been reported on devel [1,2] and might affect more Mac users when upgrading to 8.9. Perhaps a copy of sage-dist-helpers could be added back to src/bin for some deprecation period?

A symlink could do it.

Very nice sleuthing all around.  I do recommend something be done for that as a stopgap for an 8.9rc - presumably it should also be tested out.  But for people who do not regularly upgrade to betas, but do build from source, this would be quite helpful. 

[kcrisman]

For a data point, I am currently trying to use binary-pkg to create a Sage 9.0 binary for Mac, and ran into *exactly* the same issue - presumably because it (the version of Sage I had in binary-pkg, that is) had upgraded from 8.9.beta6 or so.  I guess it must have hit the window for not having this dist-helpers file around.