Sage 7.3 released

[Volker Braun]

The "master" git branch has been updated to Sage-7.3. 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

There was no change compared to 7.3.rc0

[leif]

Volker Braun wrote:
> The "master" git branch has been updated to Sage-7.3. 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

http://www.sagemath.org/download-source.html (in a while)

> There was no change compared to 7.3.rc0

Milestone: sage-7.3: 52%

Total number of tickets: 692 - closed: 363 - active: 329


Milestone: sage-7.4: 4%

Total number of tickets: 49 - closed: 2 - active: 47


-leif

[leif]

P.S.: We also have 35 positively reviewed tickets with "milestone"
sage-duplicate/invalid/wontfix [1].

@vbraun_spam: You can batch-modify them.


-leif

[1]
https://trac.sagemath.org/query?status=positive_review&milestone=sage-duplicate%2Finvalid%2Fwontfix&group=status&order=priority

[Harald Schilly]

Updated the online documentation, website will follow soon ...

-- h

[Dima Pasechnik]

On Friday, August 5, 2016 at 7:49:52 AM UTC+1, leif wrote:

leif wrote:
> Volker Braun wrote:
>> The "master" git branch has been updated to Sage-7.3. 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
>
> http://www.sagemath.org/download-source.html (in a while)
>
>> There was no change compared to 7.3.rc0
>
> Milestone: sage-7.3:  52%
>
> Total number of tickets: 692 - closed: 363 - active: 329
>
>
> Milestone: sage-7.4:  4%
>
> Total number of tickets: 49 - closed: 2 - active: 47

P.S.:  We also have 35 positively reviewed tickets with "milestone"
sage-duplicate/invalid/wontfix [1].

 

more properly called "tombstone" :-) 

[leif]

Dima Pasechnik wrote:
>
>
> On Friday, August 5, 2016 at 7:49:52 AM UTC+1, leif wrote:
>
> leif wrote:
> >
> > Milestone: sage-7.3: 52%
> >
> > Total number of tickets: 692 - closed: 363 - active: 329
> >
> >
> > Milestone: sage-7.4: 4%
> >
> > Total number of tickets: 49 - closed: 2 - active: 47
>
> P.S.: We also have 35 positively reviewed tickets with "milestone"
> sage-duplicate/invalid/wontfix [1].
>
>
> more properly called "tombstone" :-)

No, the tombstones (or zombies?) are these:

https://trac.sagemath.org/query?status=needs_info&status=needs_review&status=needs_work&status=new&status=positive_review&milestone=sage-6.4&col=id&col=summary&col=owner&col=type&col=status&col=priority&col=component&order=priority


and more (for other milestones below 7.3).


Again something for vbraun_spam :P


I've changed the default milestone, but haven't closed 7.3 yet, and
certainly won't move the ~329 open tickets for 7.3 to 7.4 (not to
mention the 1881 from 6.4 given above)...


sudo use Milestone for milestones and Version for versions


-leif

>
>
> @vbraun_spam: You can batch-modify them.
>
>
> -leif
>
> [1]
> https://trac.sagemath.org/query?status=positive_review&milestone=sage-duplicate%2Finvalid%2Fwontfix&group=status&order=priority

> <https://trac.sagemath.org/query?status=positive_review&milestone=sage-duplicate%2Finvalid%2Fwontfix&group=status&order=priority>

[Ralf Stephan]

On Fri, Aug 5, 2016 at 11:05 AM leif <not.r...@online.de> wrote:

No, the tombstones (or zombies?) are these:

Huh. I just started work on one of these half an hour ago.

So call me ghoul or ?

[leif]

Solange daraus keine Leichenfledderei wird, ok. (Schon der Versuch ist
strafbar [1].)


-leif

[1] https://dejure.org/gesetze/StGB/168.html

[kcrisman]

>
> On Fri, Aug 5, 2016 at 11:05 AM leif <not.r...@online.de
> <mailto:not.r...@online.de>> wrote:
>
>     No, the tombstones (or zombies?) are these:
>
>
> Huh. I just started work on one of these half an hour ago.
> So call me ghoul or ?

Solange daraus keine Leichenfledderei wird, ok.  (Schon der Versuch ist
strafbar [1].)

Oder aber:

http://stackoverflow.com/help/badges/17/necromancer 

"Awarded 291312 times"

Though in this case it might be better to start not having a milestone and then only 'awarding' a milestone to tickets with positive review, since we have little meaningful triage on Trac.

[Volker Braun]

binaries are now on the way to the mirrors...

[Jan Groenewald]

Hi

I'd expected the 32 bit binaries for sage 7.3 ubuntu 14.04, 15.10, 16.04 to show up here already? Perhaps some transfer fell over?

http://files.sagemath.org/linux/32bit/index.html

It only shows 12.04.

Regards,

Jan

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

--

  .~.
  /V\     Jan Groenewald
 /( )\    www.aims.ac.za
 ^^-^^ 

[Jan Groenewald]

Hi

On 10 August 2016 at 08:09, Jan Groenewald <j...@aims.ac.za> wrote:

Hi

I'd expected the 32 bit binaries for sage 7.3 ubuntu 14.04, 15.10, 16.04 to show up here already? Perhaps some transfer fell over?

http://files.sagemath.org/linux/32bit/index.html

It only shows 12.04.

I am bumping this as I was waiting for the 14.04 32bit binary before releasing the 32+64bit via the Ubuntu PPA.

Regards,

Jan

[Volker Braun]

Some of the 32-bit buildbots (including 14.04)  failed to build a binary because they segfault when building docs; This does not happen for normal builds. Haven't had time to investigate.

http://build.sagedev.org/release/builders/Zpkg%20%20slow%20AIMS%20bu14_32s02%20%28Ubuntu%2014.04%2032%20bit%29%20pkg-binary/builds/12

[Francois Bissey]

Stack smashing on 32bits
[dochtml] Setting permissions of DOT_SAGE directory so only you can read and write it.
[dochtml] *** stack smashing detected ***: python terminated
[dochtml] ------------------------------------------------------------------------
[dochtml]

I/We had to deal with that before, in singular, if memory serves me right.

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.

[Francois Bissey]

> On 18/08/2016, at 19:38, Francois Bissey <francoi...@canterbury.ac.nz> wrote:
>
> Stack smashing on 32bits
> [dochtml] Setting permissions of DOT_SAGE directory so only you can read and write it.
> [dochtml] *** stack smashing detected ***: python terminated
> [dochtml] ------------------------------------------------------------------------
> [dochtml]
>
> I/We had to deal with that before, in singular, if memory serves me right.
>

Hum, was at linking time not run time. May have to inspect more carefully but
-fno-stack-protector may come in handy somewhere.

François

[leif]

FWIW, attached are some excerpts from the log, with also some "funny"
errors I at least never noticed before.

As you may already have seen, the crash starts somewhere in
sage/rings/number_field/totallyreal.so, goes through some
Singular-related extension modules up to sage/libs/singular/singular.so,
and "ends" in local/lib/libsingular.so.

Compiler is Ubuntu's "native" GCC 4.8.4-2ubuntu1~14.04.3
(--with-arch-32=i686 --with-tune=generic target=i686-linux-gnu), not
Sage's 4.9.3.

Build is in some VM on a 64-bit machine (Linux sagebu14_32s02
4.5.0-0.bpo.2-amd64 #1 SMP Debian 4.5.4-1~bpo8+1 (2016-05-13) i686 i686
i686 GNU/Linux).


-leif

[leif]

leif wrote:
> Francois Bissey wrote:
>>
>>> On 18/08/2016, at 19:38, Francois Bissey <francoi...@canterbury.ac.nz> wrote:
>>>
>>> Stack smashing on 32bits
>>> [dochtml] Setting permissions of DOT_SAGE directory so only you can read and write it.
>>> [dochtml] *** stack smashing detected ***: python terminated
>>> [dochtml] ------------------------------------------------------------------------
>>> [dochtml]
>>>
>>> I/We had to deal with that before, in singular, if memory serves me right.
>>>
>>
>> Hum, was at linking time not run time. May have to inspect more carefully but
>> -fno-stack-protector may come in handy somewhere.
>
> FWIW, attached are some excerpts from the log, with also some "funny"
> errors I at least never noticed before.
>
> As you may already have seen, the crash starts somewhere in
> sage/rings/number_field/totallyreal.so, goes through some
> Singular-related extension modules up to sage/libs/singular/singular.so,
> and "ends" in local/lib/libsingular.so.
>
> Compiler is Ubuntu's "native" GCC 4.8.4-2ubuntu1~14.04.3
> (--with-arch-32=i686 --with-tune=generic target=i686-linux-gnu), not
> Sage's 4.9.3.

As expected, the last *successful* build on that machine was in May, for
Sage *7.2*, and with SAGE_INSTALL_GCC=yes, i.e., using Sage's GCC 4.9.3,
not Ubuntu's.


-leif

P.S.: The error in building NTL is also harmless; it happens during
tuning (trying various different implementations, including such with
inappropriate instructions).

[leif]

Volker Braun wrote:
> binaries are now on the way to the mirrors...

Is a Sage 7.3 OVA also in preparation (or even already on the way)?


-leif

[leif]

leif wrote:
> leif wrote:
>> Francois Bissey wrote:
>>>
>>>> On 18/08/2016, at 19:38, Francois Bissey <francoi...@canterbury.ac.nz> wrote:
>>>>
>>>> Stack smashing on 32bits
>>>> [dochtml] Setting permissions of DOT_SAGE directory so only you can read and write it.
>>>> [dochtml] *** stack smashing detected ***: python terminated
>>>> [dochtml] ------------------------------------------------------------------------
>>>> [dochtml]
>>>>
>>>> I/We had to deal with that before, in singular, if memory serves me right.
>>>>
>>>
>>> Hum, was at linking time not run time. May have to inspect more carefully but
>>> -fno-stack-protector may come in handy somewhere.
>>
>> FWIW, attached are some excerpts from the log, with also some "funny"
>> errors I at least never noticed before.
>>
>> As you may already have seen, the crash starts somewhere in
>> sage/rings/number_field/totallyreal.so, goes through some
>> Singular-related extension modules up to sage/libs/singular/singular.so,
>> and "ends" in local/lib/libsingular.so.
>>
>> Compiler is Ubuntu's "native" GCC 4.8.4-2ubuntu1~14.04.3
>> (--with-arch-32=i686 --with-tune=generic target=i686-linux-gnu), not
>> Sage's 4.9.3.
>
> As expected, the last *successful* build on that machine was in May, for
> Sage *7.2*, and with SAGE_INSTALL_GCC=yes, i.e., using Sage's GCC 4.9.3,
> not Ubuntu's.

P.P.S.:

Just recalled in Sage 7.3 we also still have Singular (and libsingular)
linking to *both* MPIR and GMP (an almost identical *copy* of the
former), which *might* be relevant here as well, or is at least likely
to cause /additional/ trouble in "fat" builds.

[leif]

Volker Braun wrote:
> Some of the 32-bit buildbots (including 14.04) failed to build a binary
> because they segfault when building docs; This does not happen for
> normal builds. Haven't had time to investigate.
>
> http://build.sagedev.org/release/builders/Zpkg%20%20slow%20AIMS%20bu14_32s02%20%28Ubuntu%2014.04%2032%20bit%29%20pkg-binary/builds/12

Is there demand for sage-7.3-Ubuntu_{14.04,15.10,16.04}-i686.tar.bz2?
(After all, Ubuntu stopped "recommending" their 32-bit OS versions even
on 64-bit machines.)

Did the other builds fail in the same way?

Is anybody going to investigate the issue(s)? (See also my other replies.)


-leif

> On Thursday, August 18, 2016 at 6:52:26 AM UTC+2, pipedream wrote:
>
> Hi
>
> On 10 August 2016 at 08:09, Jan Groenewald <j...@aims.ac.za

> <javascript:>> wrote:
>
> Hi
>
> I'd expected the 32 bit binaries for sage 7.3 ubuntu 14.04,
> 15.10, 16.04 to show up here already? Perhaps some transfer fell
> over?
>
> http://files.sagemath.org/linux/32bit/index.html
> <http://files.sagemath.org/linux/32bit/index.html>
>
> It only shows 12.04.
>
>
> I am bumping this as I was waiting for the 14.04 32bit binary before
> releasing the 32+64bit via the Ubuntu PPA.
>
> Regards,
> Jan
>
> --
> .~.
> /V\ Jan Groenewald

> /( )\ www.aims.ac.za <http://www.aims.ac.za>
> ^^-^^

[leif]

leif wrote:
> Volker Braun wrote:
>> binaries are now on the way to the mirrors...
>
> Is a Sage 7.3 OVA also in preparation (or even already on the way)?

Orthogonal to that, would including all or most of the upstream tarballs
of optional (and probably also experimental) packages significantly blow
up the image?

That way we would avoid some of the typical network issues in the VM.


-leif

[Harald Schilly]

On Sat, Aug 20, 2016 at 4:40 PM, leif <not.r...@online.de> wrote:
> Is there demand for sage-7.3-Ubuntu_{14.04,15.10,16.04}-i686.tar.bz2?
> (After all, Ubuntu stopped "recommending" their 32-bit OS versions even
> on 64-bit machines.)
>

So, the only thing I can offer are javascript events when you click on
a download. That doesn't say much, though. Data says:

all for ubuntu, unique events, for the past 3 months:

sage 7.2, 16.04, 64bit, 337 normal + 51 torrent dls
sage 7.2, 14.04, 64bit, 190 normal + 36 torrent dls
sage 7.3, 16.04, 64bit, 87 + 15
sage 7.2, 16.04. 32bit, 76
...
two 7.1s with 37 and 31 dls
...
sage 7.2, 14.04, 32bit, 20

this is incomplete, but it looks like the total demand is somewhere at
10% to 15% of the downloads.

and for context, the top download is the OVA. It has 3546 + 828 dls,
which is about 50% of all downloads overall. and they're followed by
the ones for OSX.

-- harald

[Jan Groenewald]

Hi

0 jan@debian:~$for i in precise trusty; do for j in amd64 i386; do echo $i $j; python bin/ppastats.py aims sagemath $i $j; done; done
precise amd64
sagemath-upstream-binary    6.1.1ubuntu2    9648
precise i386
trusty amd64
sagemath-upstream-binary    7.2~aimsppa1    7557
sagemath-upstream-binary-full    7.2~aimsppa1    315
trusty i386
sagemath-upstream-binary    7.2~aimsppa1    306
sagemath-upstream-binary-full    7.2~aimsppa1    26
0 jan@debian:~$

Note that trusty actually includes trusty vivid wily xenial since I copy the trusty binary forward in the PPA. I think maybe that is unique IPs so computer labs could be under represented.

https://blog.launchpad.net/cool-new-stuff/tracking-ppa-download-statistics
https://askubuntu.com/questions/296197/how-to-find-out-the-package-download-count-from-a-ppa

Regards,

Jan

--

  .~.
  /V\     Jan Groenewald
 /( )\    www.aims.ac.za

 ^^-^^ 

[leif]

Jan Groenewald wrote:
> Hi
>
> On 20 August 2016 at 19:36, Harald Schilly <harald....@gmail.com

> <mailto:harald....@gmail.com>> wrote:
>
> On Sat, Aug 20, 2016 at 4:40 PM, leif <not.r...@online.de
> <mailto:not.r...@online.de>> wrote:
> > Is there demand for sage-7.3-Ubuntu_{14.04,15.10,16.04}-i686.tar.bz2?
> > (After all, Ubuntu stopped "recommending" their 32-bit OS versions even
> > on 64-bit machines.)
> >
>
>
> So, the only thing I can offer are javascript events when you click on
> a download. That doesn't say much, though. Data says:
>
> all for ubuntu, unique events, for the past 3 months:
>
> sage 7.2, 16.04, 64bit, 337 normal + 51 torrent dls
> sage 7.2, 14.04, 64bit, 190 normal + 36 torrent dls
> sage 7.3, 16.04, 64bit, 87 + 15
> sage 7.2, 16.04. 32bit, 76
> ...
> two 7.1s with 37 and 31 dls
> ...
> sage 7.2, 14.04, 32bit, 20
>
> this is incomplete, but it looks like the total demand is somewhere at
> 10% to 15% of the downloads.

Presumably stupid question, I'm pretty ignorant w.r.t. the web stuff,
but do these figures include feedback from the mirrors (modulo "pure"
FTP downloads)?

> and for context, the top download is the OVA. It has 3546 + 828 dls,
> which is about 50% of all downloads overall. and they're followed by
> the ones for OSX.

Well, that's not too surprising, and I bet it mainly reflects that
Windows users are even less likely to build from source than MacOS X
users already are compared to *nix users. (Also, site installations, if
using binary dists at all, presumably count as one in the latter.)

But perhaps the Ubuntu downloads here also "suffer" from the
availability of the PPA.

> 0 jan@debian:~$for i in precise trusty; do for j in amd64 i386; do echo
> $i $j; python bin/ppastats.py aims sagemath $i $j; done; done
> precise amd64
> sagemath-upstream-binary 6.1.1ubuntu2 9648
> precise i386
> trusty amd64
> sagemath-upstream-binary 7.2~aimsppa1 7557
> sagemath-upstream-binary-full 7.2~aimsppa1 315
> trusty i386
> sagemath-upstream-binary 7.2~aimsppa1 306
> sagemath-upstream-binary-full 7.2~aimsppa1 26
> 0 jan@debian:~$
>
> Note that trusty actually includes trusty vivid wily xenial since I copy
> the trusty binary forward in the PPA. I think maybe that is unique IPs
> so computer labs could be under represented.

Oh, so after more than two years, precise still outperforms trusty and
all of its successors together.


Is Sage built from source on 32-bit Ubuntu > 12.04 (where Sage's GCC
does *not* by default get installed and used) at all functional? (Or,
will it pass [p]testlong?)

In contrast to Sage's vanilla FSF GCC 4.9.3, Ubuntu's GCCs use
'-fstack-protector' by default. (It's still not clear to me whether the
failure is due to a real bug, and why it apparently doesn't pop up with
64-bit builds -- the latter may be due to different alignment.)


-leif

> https://blog.launchpad.net/cool-new-stuff/tracking-ppa-download-statistics
> https://askubuntu.com/questions/296197/how-to-find-out-the-package-download-count-from-a-ppa
>
> Regards,
> Jan
>
>
>
>
> --
> .~.
> /V\ Jan Groenewald

> /( )\ www.aims.ac.za <http://www.aims.ac.za>
> ^^-^^

[leif]

leif wrote:
> *** BIG SNIP -- belongs more to another branch of this thread ***

>
> Is Sage built from source on 32-bit Ubuntu > 12.04 (where Sage's GCC
> does *not* by default get installed and used) at all functional? (Or,
> will it pass [p]testlong?)
>
> In contrast to Sage's vanilla FSF GCC 4.9.3, Ubuntu's GCCs use
> '-fstack-protector' by default. (It's still not clear to me whether the
> failure is due to a real bug, and why it apparently doesn't pop up with
> 64-bit builds -- the latter may be due to different alignment.)

I couldn't find anything relevant in the "offending" function siInit()
(defined in Singular/misc_ip.cc); AFAICS there are no local variables
that could get corrupted at all in the function itself, so they
apparently originate from macros or inlined functions, with debug info
lost during optimization.

So someone should really try to reproduce the error on 32-bit Ubuntu
14.04 or 16.04, or inspect the code generated by Ubuntu's GCC.


-leif

[Jan Groenewald]

Hi

On 21 August 2016 at 00:07, leif <not.r...@online.de> wrote:

Oh, so after more than two years, precise still outperforms trusty and
all of its successors together

I don't think so. The precise repo has an old version that is never updated, so that version shows many downloads.

The trusty repo is updated roughly every 3 months, and the download numbers are only for the last relrease.

That means trusty (and successors) almost reach as many downloads in 3 months as precise took 4 years to reach.

Regards,

Jan

--

  .~.
  /V\     Jan Groenewald
 /( )\    www.aims.ac.za

 ^^-^^