Sage 6.1 released

[Volker Braun]

I'm pleased to announce the release of Sage-6.1!

This means that now the "master" branch changed for the first time, and now points to the new stable release. The "develop" branch for now also points to the very same stable release, but will move on once the first beta version is ready. As always, you can also check out a version tag (namely "6.1") if you want a particular version from the git repo.

Source tarball is here (to be uploaded to the mirrors):

http://boxen.math.washington.edu/home/release/sage-6.1/sage-6.1.tar.gz

md5sum = 75130374fcdb9395955db81f1ed28422

Binary builds will be posted when they are finished. Also, I hope that Jeroen will post an overview over the changes from 6.0 to 6.1.

Changelog:

$ git log --author 'Release Manager' --oneline  6.1 ^6.1.rc0

022e2ce Trac #15719: Fix documentation bugs

[Harald Schilly]

On Thu, Jan 30, 2014 at 10:08 PM, Volker Braun <vbrau...@gmail.com> wrote:
> Source tarball is here (to be uploaded to the mirrors):

Cool! I've already started to move it to the mirrors.

Harald

[John Cremona]

Good! Now here is a question I have been waiting to ask:

We know know that it is Not A Good Idea to build Sage in one place and
move it, so when I install Sage system-wode on the machines I
administer, which I only do for full releases (not betas etc), I have
been building it where I want it (in /usr/local/sage) and then
switching /usr/local/bin/sage which is a symlink to point to the new
version.

Now with the new build system I could, but would prefer not to, build
from scratch for this purpose, but would like to go in to my
/usr/local/sage/ build, pull the new master and rebuild. BUT if I do
that then while the new version is building it will be unavailable to
users, which is not ideal.

Am I missing something simple? What do other people who manage
systems with several users do or plan to do?

John

> --
> 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 http://groups.google.com/group/sage-release.
> For more options, visit https://groups.google.com/groups/opt_out.

[Dima Pasechnik]

On 2014-01-31, John Cremona <john.c...@gmail.com> wrote:
> Good! Now here is a question I have been waiting to ask:
>
> We know know that it is Not A Good Idea to build Sage in one place and
> move it, so when I install Sage system-wode on the machines I
> administer, which I only do for full releases (not betas etc), I have
> been building it where I want it (in /usr/local/sage) and then
> switching /usr/local/bin/sage which is a symlink to point to the new
> version.
>
> Now with the new build system I could, but would prefer not to, build
> from scratch for this purpose, but would like to go in to my
> /usr/local/sage/ build, pull the new master and rebuild. BUT if I do
> that then while the new version is building it will be unavailable to
> users, which is not ideal.
>
> Am I missing something simple? What do other people who manage
> systems with several users do or plan to do?

make somewhere a symbolic link to the current system-wide Sage
installation, e.g.
/usr/local/sage/current a symlink to
/usr/local/sage/sage-6.0/

As well, make /usr/local/bin/sage a symlink to
/usr/local/sage/current/sage

Done!

Now you can happily build in /usr/local/sage/sage-6.1 and
at some point switch your /usr/local/sage/current to point to
/usr/local/sage/sage-6.1/

HTH,
Dima

[Volker Braun]

I would just build /usr/local/sage-x.y.z and then switch the symlink. That way you can also have multiple old Sage versions around if you want to. You can share the upstream folder if you make it a symlink to a common directory.

[Volker Braun]

Most binaries are now at http://boxen.math.washington.edu/home/buildbot/binaries/, two more to come.

[John Cremona]

Thanks for all the comments. Until we have dealt with the issue of
moving after building, I'll just build from scratch.

John

[Volker Braun]

All binary builds are now finished. 

Harald: please mirror...

[Harald Schilly]

Are there already somewhere the release notes? And if not, does anybody have an idea where the script for creating it is? 

Harald

[John Cremona]

After pulling the latest develop commits from trac and doing make, I
get errors building the docs, starting at


[combinat ] /home/jec/sage/src/doc/en/reference/combinat/algebra.rst:4:
WARNING: toctree contains reference to nonexisting document
u'sage/combinat/free_module'

How should I fix that?

John

[Jeroen Demeyer]

On 2014-02-02 23:18, Harald Schilly wrote:
> Are there already somewhere the release notes? And if not, does anybody
> have an idea where the script for creating it is?

There are some issues, both of them causing extra tickets to appear in
the changelog:

1) There are duplicate commits for various (maybe all?) tickets from
sage-5.13.beta5 appearing in the changelog, how did that happen?

For example, there is (merged in 5.13.beta5)

commit 84c206a4d2b0f6fb80ffc14fcb16f1650c85e646
Author: Jeroen Demeyer <jdem...@cage.ugent.be>
Date: Mon Nov 25 22:57:34 2013 +0100

Trac #15453: Wrap IML calls in sig_on()

But now also (merged in 6.1.beta2)

commit 1331eba6caa5107cd48b243494652b29f453e939
Author: Jeroen Demeyer <jdem...@cage.ugent.be>
Date: Mon Nov 25 22:57:34 2013 +0100

Trac #15453: Wrap IML calls in sig_on()


2) Every ticket ever merged in prereq appears in
git log 6.1.beta5 ^6.1.beta4

[Volker Braun]

In b554827a94872c3e62cd7311c22e28d38e635ffc Travis started a new branch on top of a rebased tree, or the master tree was yanked from under his feet. In any case, it shouldn't happen again but there is no point in beating yourself up over mistakes that were made.

On Monday, February 3, 2014 9:51:17 AM UTC, Jeroen Demeyer wrote:

2) Every ticket ever merged in prereq appears in
git log 6.1.beta5 ^6.1.beta4

This works as it should for me:

$ git log 6.1.beta5 ^6.1.beta4 --oneline | wc

    147    1121    8347

$ git log 6.1.beta5 ^6.1.beta4 --oneline --author='Release Manager'

ea36c89 Trac #15580: Integrate prereq in the new build system

7587b0d Trac #14824: Frobenius endomorphism over p-adics

f3d41ff Trac #15265: Additional functionality for Farey symbols

253ac07 Trac #14971: Better latex for Farey symbols

140d055 Trac #13379: Add a splitting field function for polynomials over a finite field

075fd2c Trac #13163: E.minimal_model() crashes with large coefficients.

b9f86e1 Trac #10255: Correct karatsuba multiplication of univariate polynomials for different degree polynomials

8a93e54 Trac #15380: Improving documentation for triangular module morphisms

e48fdd9 Trac #15518: Implement getattr() using closures

a71fc88 Trac #1314: graphs: calculate tutte polynomial

584a7cd Trac #15652: Always add -fno-strict-aliasing when compiling Cython code

462a639 Trac #15653: Trac 12555 broke conversion of zero p-adics to PARI

333dccc Trac #15607: Upgrade database_stein_watkins to the 2007 data

980c737 Trac #8305: Improve documentation of Monsky-Washnitzer code

109756c Trac #11211: elliptic curve p-adic L-series claims to default to eclib but doesn't

ccb0f3a Trac #5903: Remove dist directories from Sage distribution

1a959cd Trac #15640: Segfault on negative powers in fixed mod elements

a1f7153 Trac #15614: Update Cremona's table of elliptic curves to 320000

e2ba2a5 Trac #15613: Implementation for check of perfectness for CrystalOfProjectedLevelZeroLSPaths

755917c Trac #15576: Semimonomial transformation groups code is sensitive to Permutations global options

9dd1e6b Trac #14823: Categories of (C)DVR and (C)DVF

4eafc31 Trac #11905: Implement division_field() for elliptic curves

e4b839f Trac #15591: sum(...) misbehaves on tropical semiring

c1517a3 Trac #15550: Implement the Kirchhoff-Symanzik polynomial for graphs

922d290 Trac #15638: Recompiling an extension every time we rebuild

598760f Trac #15626: Further improvements to splitting_field()

bc3fe82 Trac #15622: Immutable graphs must not be relabeled

[John Cremona]

On 3 February 2014 09:42, John Cremona <john.c...@gmail.com> wrote:
> After pulling the latest develop commits from trac and doing make, I
> get errors building the docs, starting at
>
>
> [combinat ] /home/jec/sage/src/doc/en/reference/combinat/algebra.rst:4:
> WARNING: toctree contains reference to nonexisting document
> u'sage/combinat/free_module'
>
> How should I fix that?

I deleted all of src/doc/output and re-made, and the problem went away.

John

[Volker Braun]

On Monday, February 3, 2014 12:04:58 PM UTC, John Cremona wrote:

I deleted all of src/doc/output and re-made, and the problem went away.

You can also "make doc-clean" 

[kcrisman]

So... is the release script not being used any more to at least add to the release log?  "So and so many new contributors" etc?  This would be really really unfortunate, and I think Jeroen even put his script in a public place it could easily be used by someone knowledgeable about release management...

This is not good:

http://sagemath.org/mirror/src/changelogs/sage-6.1.txt

404 Error: page not found

Requested page /mirror/src/changelogs/sage-6.1.txt could not be found.

[Jeroen Demeyer]

On 2014-02-03 12:57, Volker Braun wrote:
> --author='Release Manager'
OK, I will add this option.

[Emmanuel Charpentier]

I tried installing "the classic way", i. e. from the tarball (as mirrored at Paris-VI university).

On a "big laptom" (Core i7, 16 GB RAM) under Debian testing, a parallel compilation (export MAKE="make -j8 -l10" ; time make ssl) t took almost 4 hours :
real    215m37.165s
user    369m27.220s
sys    10m40.716s

of this time, installing pyopenssl took 2.6 seconds.

Compiling sage 6.0 (installed by cloning the git directory) took about 40-45 minutes a while back. !!!

For what it's worth, ATLAS compilation seemed (at visual examination of the compilation console) to be the bottleneck : this console "froze" minutes at a time showing results of ATLAS optimizing tests. At the end of the atlas log, I find this :
real    191m4.515s
user    177m51.532s
sys     5m27.992s

Intrigued by this result, I launched a *serial* compilation on another desktop machine (Xeon, 8 threads, 8 GB RAM). That went much faster :
real    173m23.190s
user    162m59.508s
sys    5m56.480s

As for atlas :
real    11m4.562s
user    12m37.052s
sys     0m52.264s

Tentative conclusion : as distributed in the tarball, parallel compilation of atlas seems to have a (serious) problem.

Should this be filed as a ticket ?

Emmanuel Charpentier

[Volker Braun]

Atlas compile time mostly depends on whether atlas has pre-computed defaults for your cpu, not so much on the CPU speed. If it bothers you, use the SAGE_ATLAS_LIB environment variable to use a system/previously-compiled library

[Nathann Cohen]

> Atlas compile time mostly depends on whether atlas has pre-computed defaults
> for your cpu, not so much on the CPU speed. If it bothers you, use the
> SAGE_ATLAS_LIB environment variable to use a system/previously-compiled
> library

HMmm.... Looks like debian's packages do not contain the
"libptf77blas" and "libptcblas" files that [1] says we need :-/

Nathann

[1] http://www.sagemath.org/doc/installation/source.html

[Jean-Pierre Flori]

On Wednesday, February 5, 2014 11:46:23 AM UTC+1, Nathann Cohen wrote:

> Atlas compile time mostly depends on whether atlas has pre-computed defaults
> for your cpu, not so much on the CPU speed. If it bothers you, use the
> SAGE_ATLAS_LIB environment variable to use a system/previously-compiled
> library

HMmm.... Looks like debian's packages do not contain the
"libptf77blas" and "libptcblas" files that [1] says we need :-/

 

I'd say [1] is wrong and the *pt* files are optional.
For sure the debian libatlas-base-dev (approximate name) is enough.

[1] http://www.sagemath.org/doc/installation/source.html

[Nathann Cohen]

> I'd say [1] is wrong and the *pt* files are optional.
> For sure the debian libatlas-base-dev (approximate name) is enough.

Oh. Is there a way for me to test that Sage uses debian's files
without any problem and does not build its own atlas again ? Ideally
without rebuilding all of Sage :-P

If it does the trick then we can fix the manual.

Nathann

[Volker Braun]

If SAGE_ATLAS_LIB is set then we don't compile atlas. If the system atlas libraries don't work then you'll get an error later on, of course.

[Nathann Cohen]

> If SAGE_ATLAS_LIB is set then we don't compile atlas. If the system atlas
> libraries don't work then you'll get an error later on, of course.

Okayyyyy... Would "make" be enough to have Sage notice that a
different Atlas is to be used and that everything now has to be
recompiled with the new one ?

Otherwise I'll have to recompile everything ^^;

Nathann

[Volker Braun]

"make" doesn't know about changed environment variables, so you either recompile from scratch or keep using your current install. 

[Nathann Cohen]

> "make" doesn't know about changed environment variables, so you either
> recompile from scratch or keep using your current install.

Okayokay. Then what do we do with the manual ? Do you also think that
we can remove "libptf77blas" and "libptcblas" from the list of files
needed by atlas ?

Nathann

[Volker Braun]

Those are the multi-threaded (pthread) versions. It is preferable if you have them, though we can of course just work with the single-threaded version.

[Nathann Cohen]

> Those are the multi-threaded (pthread) versions. It is preferable if you
> have them, though we can of course just work with the single-threaded
> version.

Oh. I see. Do I patch the manual then ?

Nathann

[Jean-Pierre Flori]

Sure, that cannot hurt.

Nathann

[Nathann Cohen]

> Sure, that cannot hurt.

Well, it's now #15787.

http://trac.sagemath.org/ticket/15787

Nathann