Sage 10.5.rc0 released

176 views
Skip to first unread message

Volker Braun

unread,
Nov 16, 2024, 8:08:41 AM11/16/24
to sage-release
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


39ebbe45ca5 (tag: 10.5.rc0, github/develop) Updated SageMath version to 10.5.rc0
d9c38a7c581 gh-38966: Clean up Cygwin remnants
54af5b3708e gh-38964: Drinfeld Modules: Default to zero endomorphism in `.hom` and avoid inversion of zero endomorphism
7c13ae9c559 gh-38963: Disallow scaling of quaternion fractional ideals by zero
c007973386a gh-38961: Iteration over infinite abelian groups
09bcdd9056c gh-38957: rebase sage_autodoc to sphinx 8.1.3
ba94a5640c8 gh-38954: Fix configure script generated by pkgconf-2.3.0
2a417859d83 gh-38948: move spkg tarballs from user.ox.ac.uk
5c957f8b760 gh-38944: no longer ignore errors in method `union` of `DisjointSet`
c7e2e48888f gh-38942: deprecate is_generator for is_gen
78e68ab25f8 gh-38941: Details yang baxter
b625a146900 gh-38938: Sanity check parent of Vector_numpy_integer_dense
258a39a072f gh-38934: keep meson.build file for ext/interpreters
a26d8cd6841 gh-38932: Artifacts v4
0df1f22ff39 gh-38931: OS X: do not use -ld_classic
7254cca1f4e gh-38930: expunge is_commutative from plural
b2f2a4396bc gh-38926: Pathlib for 3 files
9730f8f1c89 gh-38925: avoid using "is_prime_field" in dynamics
dee48401d14 gh-38923: remove some deprecated functionality
af85150e46e gh-38922: remove the last use of PrincipalIdealDomain
4314f17b75d gh-38921: fixing ruff E714
d7c66faa587 gh-38919: preserve backend when using pickling/unpikling
bbf4466b341 gh-38917: Allow optional elliptic curve data from database_cremona_ellcurve
3401774bfc3 gh-38916: Fix Ginac cast error
a71096f70d4 gh-38915: Remove `register` macro in Ginac
5b87a0a07ac gh-38914: Replace `os.uname` by more universal `platform.system`
29db39cf726 gh-38913: Meson: Improve handling of dependencies
461bb11f0f9 gh-38912: Replace deprecated/removed mem_fun_ref
86febcc6ab4 gh-38911: Replace division by zero with +-inf
ab3952bf16a gh-38910: Meson: minor revision
5c8186c3556 gh-38908: Don't (mis)use `prec_words_to_bits()`
813f2b5e01d gh-38907: Format function headers around `=` and `,`
1b8ac9cceaa gh-38905: Update the gcc spkg to version 14.2.0 using iains/gcc-14-branch
69a8c024b19 gh-38903: a few details in combinat, following ruff and pycodestyle
a9f3f77dce8 gh-38899: src/sage/interfaces/singular.py: use GNU Info to read Singular's info
8cf669e5283 gh-38885: Follow-up to #38822: Add missing package update in build/pkgs
5a8cfd0fbe0 gh-38875: libsemigroup upgrade to 2.7.3
e1769faab80 gh-38791: non recursive version of method `gomory_hu_tree` for graphs
0b86b7f9f30 gh-38742: Introduced the class `MatchingCoveredGraph`
8f2f636bd2d gh-38728: Improve conda setup
6fb883afd0c gh-38536: Implement dual subdivision and weight vectors for tropical variety
d6a6060401a gh-38484: Eisenstein series: Small documentation improvement
a4ed86a85e8 gh-38482: Dokchitser: Pass internal parameter over properly
776d13ccbe4 gh-38449:  Include TESTS in doc preview for PRs
4817e52e584 gh-38446: Implement basic multivariate polynomial species
980cab1499d gh-38441: number_field_elements_from_algebraics: Fix CyclotomicField embedding when embedding=False
f63dd373029 gh-38281: Addition of Chow ring ideal and Chow ring classes
209ae4c3a43 (tag: 10.5.beta9) Updated SageMath version to 10.5.beta9

David Coudert

unread,
Nov 16, 2024, 10:39:09 AM11/16/24
to sage-r...@googlegroups.com
Than k you for this new rc.

Something goes wrong with meson/conda on GitHub. 
We get  ModuleNotFoundError: No module named 'mesonpy'

See for instance
--
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 visit https://groups.google.com/d/msgid/sage-release/cdf94d5b-15b2-42ee-a238-a0f1d34803ecn%40googlegroups.com.

Dima Pasechnik

unread,
Nov 16, 2024, 4:01:18 PM11/16/24
to sage-r...@googlegroups.com
"conda install meson-python" might help.

Emmanuel Charpentier

unread,
Nov 19, 2024, 2:22:04 AM11/19/24
to sage-release

On Ubuntu 24.04 under WSL/Windows11 running on core i7 + 32 GB RAM, rebuilding 10.5.rc0 from (yet another) fresh tree suceeds (at last !) ; running ptestlonggives two permanent failures :

---------------------------------------------------------------------- sage -t --long --warn-long 30.0 --random-seed=271681158626170621579021015491689440340 src/sage/graphs/graph_latex.py # 1 doctest failed sage -t --long --warn-long 30.0 --random-seed=271681158626170621579021015491689440340 src/sage/rings/real_mpfr.pyx # 1 doctest failed ----------------------------------------------------------------------

both having already been reported more than once.

HTH,

Emmanuel Charpentier

unread,
Nov 23, 2024, 1:29:53 AM11/23/24
to sage-release
Same result on Debian testing running on core i7 + 16 GB RAM.

HTH,

Kenji Iohara

unread,
Nov 24, 2024, 5:12:25 PM11/24/24
to sage-r...@googlegroups.com
Dear all, 

 On my Mac wirh IntelCore i5, OS Vezntura 13.7.1, there is an error in the compilation of ecm-7.0.6
 
ecm-7.0.6.log

Dima Pasechnik

unread,
Nov 24, 2024, 11:12:48 PM11/24/24
to sage-r...@googlegroups.com
Could you please check whether it helps to remove

build/pkgs/ecm/patches/assembler.patch

?


On Sun, Nov 24, 2024 at 4:12 PM Kenji Iohara <simplye...@gmail.com> wrote:
>
> Dear all,
>
> On my Mac wirh IntelCore i5, OS Vezntura 13.7.1, there is an error in the compilation of ecm-7.0.6
>
>
> --
> 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 visit https://groups.google.com/d/msgid/sage-release/65F242A9-521F-4AF7-87CE-8FF5179C6CA0%40gmail.com.
> Kenji
>
> 16/11/2024 14:08、Volker Braun <vbrau...@gmail.com>のメール:
> --
> 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 visit https://groups.google.com/d/msgid/sage-release/cdf94d5b-15b2-42ee-a238-a0f1d34803ecn%40googlegroups.com.
>
>
> --
> 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 visit https://groups.google.com/d/msgid/sage-release/65F242A9-521F-4AF7-87CE-8FF5179C6CA0%40gmail.com.

Kenji Iohara

unread,
Nov 25, 2024, 6:57:40 PM11/25/24
to sage-r...@googlegroups.com
Thanks Dima. It worked. 

25/11/2024 5:12、Dima Pasechnik <dim...@gmail.com>のメール:

Kwankyu Lee

unread,
Nov 26, 2024, 2:27:52 AM11/26/24
to sage-release
On Monday, November 25, 2024 at 1:12:48 PM UTC+9 Dima Pasechnik wrote:
Could you please check whether it helps to remove

build/pkgs/ecm/patches/assembler.patch

?

Thanks. This also fixed similar ecm build failure on my macOS with Intel Xeon E5 processor.

Is there a PR for this? Removing the patch would be okay with all machines?

Dima Pasechnik

unread,
Nov 26, 2024, 6:45:37 AM11/26/24
to sage-r...@googlegroups.com
no, I have not yet opened a PR to fix it.
It was added in the PR which upgraded gcc - as it failed to build ecm on a macOS system (sic!)

We should just get rid of the gcc package, it is merely a source of bugs and a general development timesink.

Dima

Kwankyu Lee

unread,
Nov 26, 2024, 8:40:09 AM11/26/24
to sage-release
On Tuesday, November 26, 2024 at 8:45:37 PM UTC+9 Dima Pasechnik wrote:
no, I have not yet opened a PR to fix it.

The PR should be a blocker.
 
It was added in the PR which upgraded gcc - as it failed to build ecm on a macOS system (sic!)

On macOS,  I think it is the usual scenario that the system gcc(clang) is used to build sage. 

We should just get rid of the gcc package, it is merely a source of bugs and a general development timesink.

I am aware that this issue is controversial. But I am no expert in that.

If, on every platform we support, the system gcc is a prerequisite and enough to build sage, and to compile cython code in sage sessions, then I see no reason for us to carry the gcc package. I wonder what are the main arguments against it though.

Dima Pasechnik

unread,
Nov 26, 2024, 11:07:24 AM11/26/24
to sage-r...@googlegroups.com
On Tue, Nov 26, 2024 at 7:40 AM Kwankyu Lee <ekwa...@gmail.com> wrote:
>
> On Tuesday, November 26, 2024 at 8:45:37 PM UTC+9 Dima Pasechnik wrote:
>
> no, I have not yet opened a PR to fix it.
>
>
> The PR should be a blocker.

it's now https://github.com/sagemath/sage/pull/39040

Marc Culler

unread,
Nov 26, 2024, 11:58:06 AM11/26/24
to sage-release
You cannot just "get rid of the gcc package".  It is not that simple.

Getting rid of the gcc package means that you also get rid of the gfortran package.  The way that Sage builds gfortran is that it builds part of gcc (the gnu compiler collection).  That part has to include gfortran, of course, but it also has to include the gcc C compiler, since the way that gcc builds gfortran is that it first builds a C compiler and then uses that to build gfortran.

To build a C compiler one first uses a pre-existing C compiler, clang in the case of macOS, to build version 1 of the new C compiler.  Then version 1 is used to build version 2.  Then version 2 is used to build version 3.  Then the executables for version 2 and version 3 are compared.  If they are identical the build is deemed to have succeeded.

The main reason Sage needs gfortran is because Sage has a numpy spkg, and numpy needs OpenBLAS.  So Sage needs an OpenBlas spkg and that requires a fortran compiler.  If you want to "get rid of gcc" in an intelligent way, the place to begin would be with numpy.  Installing numpy with a binary wheel from pypi would relieve Sage of the need to build it.  OpenBLAS is not released as a binary package because it attempts to optimize itself for the specific hardware being used to build it.  So it is somewhat tricky to produce a binary OpenBLAS library which can be expected to work on a wide range of Intel hardware.  Sage attempts to do that, however, as does numpy for its binary wheels.

Just making the pronouncement "we should get rid of the gcc package" without having any discussion of the complicated consequences of attempting to do that, and without providing any proposal for dealing with those consequences, is irresponsible in my opinion.  And making the predictable next pronouncement "just use the homebrew gfortran" is also pretty far from dealing with the consequences, even if it might be part of an eventual solution.

- Marc

PS Some detail on the ECM patch.  Assembler files can have suffix .s .S or .sx.  The last two imply that the file should be passed through the preprocessor before being sent to the assembler.  The distinction between .s and .S causes trouble on case-insensitive filesystems.  That is the reason why the .sx extension exists.  The ECM build produces .s files which need the preprocessor  because they contain #if and #else.  The patch was an attempt to use .sx for those files instead of .s.  Evidently some Apple systems treat .s as if it were .S and others don't.

Dima Pasechnik

unread,
Nov 26, 2024, 1:17:24 PM11/26/24
to sage-r...@googlegroups.com
On Tue, Nov 26, 2024 at 10:58 AM Marc Culler <marc....@gmail.com> wrote:
>
> You cannot just "get rid of the gcc package". It is not that simple.
>
> Getting rid of the gcc package means that you also get rid of the gfortran package. The way that Sage builds gfortran is that it builds part of gcc (the gnu compiler collection). That part has to include gfortran, of course, but it also has to include the gcc C compiler, since the way that gcc builds gfortran is that it first builds a C compiler and then uses that to build gfortran.

Let's concentrate on "gcc package" as the ability of Sage to build and
use its own gcc and g++ compilers.
Removing this ability does not remove the ability to build gfortran
(even if it involves building an internal copy of a C compiler).
What's important is that this internal copy of the C compiler is in no
way used for anything except building gfortran.
(the C compiler not even installed anywhere)
Do you have any objections to removing gcc package in this sense?
If not, we can proceed with this at least, and proceed to discussing Fortran.

Yes, you are right that we certainly will want to remove the ability
to build gfortran, as well, as gfortran is also available on all the
supported platforms. And this is now a macOS-only issue.

>
> To build a C compiler one first uses a pre-existing C compiler, clang in the case of macOS, to build version 1 of the new C compiler. Then version 1 is used to build version 2. Then version 2 is used to build version 3. Then the executables for version 2 and version 3 are compared. If they are identical the build is deemed to have succeeded.
>
> The main reason Sage needs gfortran is because Sage has a numpy spkg, and numpy needs OpenBLAS. So Sage needs an OpenBlas spkg and that requires a fortran compiler. If you want to "get rid of gcc" in an intelligent way, the place to begin would be with numpy. Installing numpy with a binary wheel from pypi would relieve Sage of the need to build it. OpenBLAS is not released as a binary package because it attempts to optimize itself for the specific hardware being used to build it. So it is somewhat tricky to produce a binary OpenBLAS library which can be expected to work on a wide range of Intel hardware. Sage attempts to do that, however, as does numpy for its binary wheels.
>
> Just making the pronouncement "we should get rid of the gcc package" without having any discussion of the complicated consequences of attempting to do that, and without providing any proposal for dealing with those consequences, is irresponsible in my opinion. And making the predictable next pronouncement "just use the homebrew gfortran" is also pretty far from dealing with the consequences, even if it might be part of an eventual solution.

I repeat, from our earlier discussions: Sage is the only open source
multiplatform Python project around which tries to carry around an
ability to build a Fortran compiler. Projects with much bigger
resources (and much bigger user base), with full-time employees, such
as numpy/scipy, don't do this.

As far as I am concerned, I would be fine with declaring that we
don't support building Sage from source on macOS without Homebrew.
This would resolve the gfortran issue (subject to the necessary CI,
etc, chnages, of course).

Another way to have gfortran I am aware of is to use a standalone
gfortran macOS package provided by one of maintainers of gfortran in
Homebrew.

By the way, scipy lately (re)gained the abilty to use Apple's
Accelerate library, instead of OpenBlas.
This could be something to look into fot Sage, too.

Dima



>
> - Marc
>
> PS Some detail on the ECM patch. Assembler files can have suffix .s .S or .sx. The last two imply that the file should be passed through the preprocessor before being sent to the assembler. The distinction between .s and .S causes trouble on case-insensitive filesystems. That is the reason why the .sx extension exists. The ECM build produces .s files which need the preprocessor because they contain #if and #else. The patch was an attempt to use .sx for those files instead of .s. Evidently some Apple systems treat .s as if it were .S and others don't.
>
> On Tuesday, November 26, 2024 at 7:40:09 AM UTC-6 Kwankyu Lee wrote:
>>
>> On Tuesday, November 26, 2024 at 8:45:37 PM UTC+9 Dima Pasechnik wrote:
>>
>> no, I have not yet opened a PR to fix it.
>>
>>
>> The PR should be a blocker.
>>
>>
>> It was added in the PR which upgraded gcc - as it failed to build ecm on a macOS system (sic!)
>>
>>
>> On macOS, I think it is the usual scenario that the system gcc(clang) is used to build sage.
>>
>> We should just get rid of the gcc package, it is merely a source of bugs and a general development timesink.
>>
>>
>> I am aware that this issue is controversial. But I am no expert in that.
>>
>> If, on every platform we support, the system gcc is a prerequisite and enough to build sage, and to compile cython code in sage sessions, then I see no reason for us to carry the gcc package. I wonder what are the main arguments against it though.
>
> --
> 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 visit https://groups.google.com/d/msgid/sage-release/a20e1e5b-6347-4159-af55-301fd7af5338n%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages