Re: [sage-release] Sage 10.0.rc0 released

[Thierry]

Hi,

Sage's current openssl version (3.0.5) hass several "High severity"
vulnerabilities, see https://www.openssl.org/news/vulnerabilities.html

It would be nice to have the fixes included in the next Sage release. I am not
using github, here is a pull request (literally) to fix this :

git pull https://lipn.univ-paris13.fr/~monteil/hebergement/sage/sage.git openssl.3.0.8

(commit hash : 997a6bd35a17f5511bb12552bd676597b09f1eaf)
I checked the hash of the tarballs against the GPG signatures by upstream developers.

Tarball at : https://www.openssl.org/source/openssl-3.0.8.tar.gz

Ciao,
Thierry

P.S. Note that 3.1.0. has been very recently released, however 3.0.x is LTS and will
not have structural changes. Just in case, here is a verified branch :

git pull https://lipn.univ-paris13.fr/~monteil/hebergement/sage/sage.git openssl.3.1.0

(commit hash : 9229a2be66dc0e4f2e3f677aa515a33bfe72a873)
Tarball at : https://www.openssl.org/source/openssl-3.1.0.tar.gz




Le Sun, Apr 23, 2023 at 07:46:00AM -0700, Volker Braun a écrit :
> 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
>
>
> f3acd42678a (tag: 10.0.rc0, github/develop) Updated SageMath version to
> 10.0.rc0
> eca2a773d08 gh-35543: Cleaning set partition
> 9d8c9c05117 gh-35542: some fixes for cython-lint in various places
> e1e119463ae gh-35534: some cython-lint fixes in matroids/
> 133a345bacb gh-35533: Fix bug in graph.maximum_average_degree
> 3c2ba826156 gh-35530: some minor details in interfaces
> 12cea800735 gh-35526: fix pycodestyle E271 and E502 in pyx files
> a03f09cf594 gh-35525: cython-lint and some doc cleanup for expression.pyx
> e9b67cc117a gh-35521: `sage.combinat.sf`: re-enable a doctest
> cc0ea4d66f4 gh-35518: Improve PolynomialSequence.connected_components()
> a38a25a261e gh-35515: Bug in integer valued polys
> 803c7aacaee gh-35514: Don't force ecl lisp with `maxima -l ecl` on command
> line.
> 20d2edd1736 gh-35513: Silence initialization of giac
> 64c205c7d51 gh-35512: Improve PolynomialSequence.connection_graph()
> implementation
> db2fa5d13b1 gh-35511: Fix Graph.add_clique() for one vertex
> 0ff23f67772 gh-35510: Make BooleanPolynomial.variables() way faster
> e3636bd579c gh-35509: some cython-linting in matrix/ folder
> 2c7e16e5faf gh-35507: fix pycodestyle E303 in schemes
> 98595ef8661 gh-35506: add check for pycodestyle E502 in python files
> 80f3fd99d04 gh-35504: `build/pkgs/sphinx_{copybutton,basic_ng}`: Add conda
> info
> 41c256ae647 gh-35499: Fix test output for ipywidgets 8.0.5, part deux
> 3740e145432 gh-35478: Remove unused code from GAP interface
> b25229b6647 gh-35476: scipy: Patch out test requiring internet access
> eafd5215a28 gh-35472: Implement the Feichtner-Yuzvinsky rings for lattices
> 957e627f023 gh-35465: Fix conda workflow
> 1fc3fee5bed gh-35463: Add iterator over minimum distance k dominating sets
> ecd162be3dc gh-35462: Iterator over the minimal distance k dominating sets
> c18a3fbfe72 gh-35446: add method is_simple to permutations
> ef68bee7ccf gh-35443: Fix slow doctests or mark # long time
> c005c006d4e gh-35431: Documentation improvements for rounding methods
> 15a5078afaa gh-35389: `sage.rings.finite_rings.residue_field`:
> Modularization fixes
> 9ff469adb9c gh-35375: Fix minimal kernel basis corner cases
> 55ebb79b65a gh-35306: `sage.groups.matrix_gps`: Modularization fixes for
> imports
> 8bcce63b6a1 gh-35305: `sage.quadratic_forms`: Modularization fixes for
> imports
> 97b45d80a7c (tag: 10.0.beta9) Updated SageMath version to 10.0.beta9
>
> --
> 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/788f2bad-420b-463a-be98-4f11819d3288n%40googlegroups.com.

[Dima Pasechnik]

Thanks, it's now https://github.com/sagemath/sage/pull/35571

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-release/ZEjvpybhNZhFERjm%40metelu.net.

[Dima Pasechnik]

PS. I think openssl spkg should just be removed from Sage, it serves
no purpose as far as I can tell.

On Wed, Apr 26, 2023 at 10:32 AM Thierry
<sage-goo...@lma.metelu.net> wrote:
>

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-release/ZEjvpybhNZhFERjm%40metelu.net.

[David Roe]

On Wed, Apr 26, 2023 at 6:41 AM Dima Pasechnik <dim...@gmail.com> wrote:

PS. I think openssl spkg should just be removed from Sage, it serves
no purpose as far as I can tell.

For a long time it was very important for getting a functional Sage on MacOS; is that no longer the case?

David

  

You received this message because you are subscribed to the Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAAWYfq1X9wgnrKsQMF-7moe%3DgA2JPXYDoTsm3h8x9ssZBB-Pbw%40mail.gmail.com.

[Dima Pasechnik]

On Wed, Apr 26, 2023 at 6:25 PM David Roe <roed...@gmail.com> wrote:
>
>
>
> On Wed, Apr 26, 2023 at 6:41 AM Dima Pasechnik <dim...@gmail.com> wrote:
>>
>> PS. I think openssl spkg should just be removed from Sage, it serves
>> no purpose as far as I can tell.
>
>
> For a long time it was very important for getting a functional Sage on MacOS; is that no longer the case?

Sorry, I don't understand.

Noone I know builds Python (the only package that needs openssl) from source.
For a long time it has been perfectly possible on macOS to either use
Python from python.org, or Python from Homebrew,
or Python3 from Conda.
If you really need to build Python from source on macOS, fine, build
it yourself and install it in /usr/local.

We should remove python3 spkg, and gcc spkg too, for the same reason.
It's a ballast slowing down
Sage's progress.


Dima

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAChs6_%3DAAePqhf8yDxwUdkNNExNh6HL3__VV3Uv1O8bydOnYXw%40mail.gmail.com.

[William Stein]

On Wed, Apr 26, 2023 at 10:40 AM Dima Pasechnik <dim...@gmail.com> wrote:

> > For a long time it was very important for getting a functional Sage on MacOS; is that no longer the case?
> Sorry, I don't understand.
>
> Noone I know builds Python (the only package that needs openssl) from source.
> For a long time it has been perfectly possible on macOS to either use
> Python from python.org, or Python from Homebrew,
> or Python3 from Conda.
> If you really need to build Python from source on macOS, fine, build
> it yourself and install it in /usr/local.
>
> We should remove python3 spkg, and gcc spkg too, for the same reason.
> It's a ballast slowing down
> Sage's progress.

When I started Sage in 2004, it was entirely possible that we would
make some interesting changes to Python itself, e.g., make the
preparser into some core functionality of the parser, make integers
much faster, etc. None of that ever happened at all, and in
retrospect, since Python got so big, I'm glad it didn't (but see [1]).
The potential for such development was one of the reasons for building
Python from source, but I think that ship sailed long ago. Also, the
Python community has really grown a lot in terms of supporting
installing python anywhere. So I'm definitely not against Dima's
suggestion.

---

[1] Incidentally, I worked a lot last year on a Python parser written
in a subset of Python and hosted on a Javascript runtime, and for that
I added several of the preparser features in the "from future import
..." style of Python.

https://github.com/sagemathinc/cowasm/blob/main/python/pylang/README.md#math-extensions-like-the-sage-preparser


--
William (http://wstein.org)

[Matthias Koeppe]

On Wednesday, April 26, 2023 at 10:25:37 AM UTC-7 David Roe wrote:

On Wed, Apr 26, 2023 at 6:41 AM Dima Pasechnik <dim...@gmail.com> wrote:

PS. I think openssl spkg should just be removed from Sage, it serves
no purpose as far as I can tell.

For a long time it was very important for getting a functional Sage on MacOS; is that no longer the case?

Yes, it is still very important for exactly this reason. 

We solved the longstanding severe SSL problems of the project by making openssl 3.x a standard package.

Meta-ticket https://github.com/sagemath/sage/issues/30556 was dedicated to this.

Best practices dictate to not create real problems by addressing imaginary problems.

[Dima Pasechnik]

Best practices dictate to get rid of legacy technical baggage.

There are no SSL problems if one uses an external Python with SSL.

There is no reason not to use such an external Python, none. It might have been important 5 or 10 years ago, now it is just waste of resources to support.

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

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/b915819b-28cf-4bc4-8b8c-3313c6ced38an%40googlegroups.com.

[Matthias Koeppe]

On Wednesday, April 26, 2023 at 10:40:27 AM UTC-7 Dima Pasechnik wrote:

We should remove python3 spkg, and gcc spkg too, for the same reason.
It's a ballast slowing down Sage's progress.

This is an unsubstantiated claim that you keep repeating.

The last substantial discussion of this proposal happened in https://groups.google.com/g/sage-devel/c/NfUKjAaTcUg/m/S3EDS0odBQAJ, and since then no new points have been brought forward.

[Dima Pasechnik]

This is ludicrous. This discussion happened 2 years ago, and I really think if anyone needs a hand-built Python, they can please themselves with building it. But on macOS in particular the Python supplied by python.org has been doing fine, for years.

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

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/1f03e417-5b59-4cb8-a5cb-516935aff33fn%40googlegroups.com.

[Dima Pasechnik]

And Mattias, ffs, we are talking about removing *Python*, and you cite a thread on removing *gfortran*. This is a very bad way of conducting a discussion, and it is not the 1st time you do this sort of thing. Please stop.

On Wed, 26 Apr 2023, 20:10 Matthias Koeppe, <matthia...@gmail.com> wrote:

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

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/1f03e417-5b59-4cb8-a5cb-516935aff33fn%40googlegroups.com.

[Matthias Koeppe]

On Wednesday, April 26, 2023 at 12:14:26 PM UTC-7 Dima Pasechnik wrote:

This discussion happened 2 years ago

That's correct, and you have not brought forward any new points.

 

[Dima Pasechnik]

Godverdomme, this was about GFORTRAN!!!
WE ARE TAKLKING ABOUT PYTHON!!! PYTHON!!!

Learn to read.

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

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/27c5cb9d-76da-48d8-a7e9-defa8453a6cen%40googlegroups.com.

[William Stein]

Hi Everybody,

Just a reminder of
https://github.com/sagemath/sage/blob/develop/CODE_OF_CONDUCT.md

In particular,

1. Be friendly and patient.
2. Be welcoming.
3. Be considerate.
4. Be respectful and polite.

As a community, we've agreed that these are very reasonable ways to
conduct ourselves on this list.

-- William

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAAWYfq0xPZf6Mt10BQFOxcbfepEPN1f8O9bCfiYr-_h402Oh5A%40mail.gmail.com.



--
William (http://wstein.org)

[David Roe]

I'm sorry to have prompted another flame war, but please keep the tone polite Dima and Matthias.  I know that you're both frustrated at this issue being unresolved, but it's not appropriate to have a fight like this that goes to 2570 different people's inboxes, with frequent emails sniping at each other.

I do think it would be valuable for other people on this list to offer some thoughts on whether Sage should prioritize reducing the number of foundational packages we offer in the short term (as Dima is advocating) or keeping them to help maintain support (as Matthias is advocating).  That becomes less possible if the tone on this thread gets out of hand.

David

--

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

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/27c5cb9d-76da-48d8-a7e9-defa8453a6cen%40googlegroups.com.

[William Stein]

On Wed, Apr 26, 2023 at 12:27 PM David Roe <roed...@gmail.com> wrote:
>
> I'm sorry to have prompted another flame war, but please keep the tone polite Dima and Matthias. I know that you're both frustrated at this issue being unresolved, but it's not appropriate to have a fight like this that goes to 2570 different people's inboxes, with frequent emails sniping at each other.
>
> I do think it would be valuable for other people on this list to offer some thoughts on whether Sage should prioritize reducing the number of foundational packages we offer in the short term (as Dima is advocating) or keeping them to help maintain support (as Matthias is advocating). That becomes less possible if the tone on this thread gets out of hand.
> David
>

Thanks David. I always posted a reminder about the code of conduct.
Also a reminder that https://groups.google.com/g/sage-flame is an
appropriate place for unrestrained debate.

Regarding your question David, I really like the way it is phrased,
since whether or not to support
packages is a function of the resources we have, which really is a
function of the community
and their availability to work on things. It's not something
intrinsic to our project. For example,
conda can support a massive number of packages, partly because they
have a massive community
that is stepping up to do it.

>
> On Wed, Apr 26, 2023 at 3:18 PM Matthias Koeppe <matthia...@gmail.com> wrote:
>>
>> On Wednesday, April 26, 2023 at 12:14:26 PM UTC-7 Dima Pasechnik wrote:
>>
>> This discussion happened 2 years ago
>>
>>
>> That's correct, and you have not brought forward any new points.
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups "sage-devel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/27c5cb9d-76da-48d8-a7e9-defa8453a6cen%40googlegroups.com.
>
> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAChs6_mzNg%3D5EyjBjOXMSvTKEECWW7QD%2BzyQCkZ1Na45kk5GSw%40mail.gmail.com.



--
William (http://wstein.org)

[Matthias Koeppe]

On Wednesday, April 26, 2023 at 12:33:13 PM UTC-7 William Stein wrote:

On Wed, Apr 26, 2023 at 12:27 PM David Roe <roed...@gmail.com> wrote:
> I do think it would be valuable for other people on this list to offer some thoughts on whether Sage should prioritize reducing the number of foundational packages we offer in the short term (as Dima is advocating) or keeping them to help maintain support (as Matthias is advocating).

Regarding your question David, I really like the way it is phrased,
since whether or not to support
packages is a function of the resources we have, which really is a
function of the community

and their availability to work on things. [...]

Actually the question happens to mischaracterize my position. I'm in favor of removing unmaintained packages from our distribution when there are *real* problems. For example, I pushed for removing the R package because it was long outdated and nobody was stepping up to take care of it and much better ways to install it than we offered. But the python3 package (and the gcc/gfortran package, which Dima brought up again in https://groups.google.com/g/sage-devel/c/LWKdRM2Gn-s/m/GAuPgzCACwAJ above) have concrete purposes of platform support and ease of install. And these packages do not have a *real* maintenance problem. (I have maintained them since 2020.) So demanding that we need to drop these packages is attempting to manage my time, which is not necessary.

Moreover, the question poses a false dichotomy; there is a third option. Quoting my key message from that very sage-devel thread from 2 years ago

(https://groups.google.com/g/sage-devel/c/NfUKjAaTcUg/m/GLMxIirPAwAJ (link to message)):

> If we say that availability of gfortran in any of these user-installable distributions is the solution, then this applies to lots of other spkgs as well --- perhaps to ALL of our non-Python packages.

> So essentially it is to say, let's stop maintaining the Sage distribution. 

> 

> This certainly *could* make sense for the project -- but a lot of work is needed to bring missing packages to these distributions: conda-forge does not have all of our optional packages, homebrew is missing a lot of packages. On the Sage side, also working on the tasks https://trac.sagemath.org/ticket/30914 (creating proper upstreams for some Sage-specific packages) will help.

>

> The big problem is that the middle ground between "Complete Sage distribution that works in most use cases" and "No Sage distribution" is worse than both of the extremes. By removing spkgs one by one, we would make the Sage distribution less useful. So this is not a meaningful process.

My 2023 summary of the situation: 

1. I would be in favor of abandoning the Sage distribution (despite the fact that I have certainly put a lot of time and energy into it) **if** it is determined that the user community is sufficiently served by conda-forge packaging. 

But I think that this would require for more developers to engage with the conda-related issues (example: https://github.com/sagemath/sage/issues/35528).

2. I'm not in favor of chipping away 1 package at a time in the name of unsubstantiated, vague notions that a package is "ballast slowing down Sage's progress".

[Jaap Spies]

Dima,

The word "G..v..d...e" is the worst curse in the Dutch language. The first three letters needs no translation. The rest translates to 'damn'. You shouldn't use it lightly.

Jaap

Op wo 26 apr. 2023 21:20 schreef Dima Pasechnik <dim...@gmail.com>:

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAAWYfq0xPZf6Mt10BQFOxcbfepEPN1f8O9bCfiYr-_h402Oh5A%40mail.gmail.com.

[Dima Pasechnik]

On Wed, Apr 26, 2023 at 9:06 PM Matthias Koeppe
<matthia...@gmail.com> wrote:
>
> On Wednesday, April 26, 2023 at 12:33:13 PM UTC-7 William Stein wrote:
>
> On Wed, Apr 26, 2023 at 12:27 PM David Roe <roed...@gmail.com> wrote:
> > I do think it would be valuable for other people on this list to offer some thoughts on whether Sage should prioritize reducing the number of foundational packages we offer in the short term (as Dima is advocating) or keeping them to help maintain support (as Matthias is advocating).
>
> Regarding your question David, I really like the way it is phrased,
> since whether or not to support
> packages is a function of the resources we have, which really is a
> function of the community
> and their availability to work on things. [...]
>
>
> Actually the question happens to mischaracterize my position. I'm in favor of removing unmaintained packages from our distribution when there are *real* problems. For example, I pushed for removing the R package because it was long outdated and nobody was stepping up to take care of it and much better ways to install it than we offered. But the python3 package (and the gcc/gfortran package, which Dima brought up again in https://groups.google.com/g/sage-devel/c/LWKdRM2Gn-s/m/GAuPgzCACwAJ above) have concrete purposes of platform support and ease of install.

gcc (a package that provides C/C++ compilers, not to be mistaken with
gfortran) has absolutely no use in 2023 (apart from some people now
and then trying and failing to build it on a system with a bad
toolchain, and wasting out time asking for help to build these)

dutto python3 package.

ditto the whole Jupyter ecosystems, with their ever growing number of
dependencies.

> And these packages do not have a *real* maintenance problem. (I have maintained them since 2020.) So demanding that we need to drop these packages is attempting to manage my time, which is not necessary.

well, we can barely keep up with security updates for e.g. openssl. It
took Thierry to provide a patch today, and me converting it into a PR,
else we probably would be still shipping openssl version with severe
CVEs. And this shows that we do have a real maintainance problem:
the fact that you, Matthias, (try to) maintain these unneeded packages
takes toll on other developers, cause it's a never ending task to
carry the dependency buggage, review corresponding PRs, etc. Sage is
not a single person project, and so it's not only your time, Matthias,
it's other people's time you take away from them, because you want to
carry this unneeded baggage forward.
Instead of e.g. updating openssl we could have done something more
meaningful today.

>
> Moreover, the question poses a false dichotomy; there is a third option. Quoting my key message from that very sage-devel thread from 2 years ago
> (https://groups.google.com/g/sage-devel/c/NfUKjAaTcUg/m/GLMxIirPAwAJ (link to message)):
> > If we say that availability of gfortran in any of these user-installable distributions is the solution, then this applies to lots of other spkgs as well --- perhaps to ALL of our non-Python packages.
> > So essentially it is to say, let's stop maintaining the Sage distribution.
> >
> > This certainly *could* make sense for the project -- but a lot of work is needed to bring missing packages to these distributions: conda-forge does not have all of our optional packages, homebrew is missing a lot of packages. On the Sage side, also working on the tasks https://trac.sagemath.org/ticket/30914 (creating proper upstreams for some Sage-specific packages) will help.
> >
> > The big problem is that the middle ground between "Complete Sage distribution that works in most use cases" and "No Sage distribution" is worse than both of the extremes. By removing spkgs one by one, we would make the Sage distribution less useful. So this is not a meaningful process.

I don't think this is true. Noone will even notice removal of gcc the
spkg, or python3. It will become more useful, as it will have less
obsolete parts, which nobody uses, but which demand constant
attention and resourses, as more time could be put into important
parts.

>
> My 2023 summary of the situation:
>
> 1. I would be in favor of abandoning the Sage distribution (despite the fact that I have certainly put a lot of time and energy into it) **if** it is determined that the user community is sufficiently served by conda-forge packaging.
> But I think that this would require for more developers to engage with the conda-related issues (example: https://github.com/sagemath/sage/issues/35528).

This can be done if we drop the ballast, not any other way.

>
> 2. I'm not in favor of chipping away 1 package at a time in the name of unsubstantiated, vague notions that a package is "ballast slowing down Sage's progress".

It's not vague, it's very concrete. It has been done in the past, cf
e.g. R/rpy2, tar, etc., it can be continued just fine.

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

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/ffb0b1f4-a143-46df-b65f-b9ac3ad3e70dn%40googlegroups.com.

[Matthias Koeppe]

On Wednesday, April 26, 2023 at 1:46:41 PM UTC-7 Dima Pasechnik wrote:

On Wed, Apr 26, 2023 at 9:06 PM Matthias Koeppe
<matthia...@gmail.com> wrote:
> My 2023 summary of the situation:
>
> 1. I would be in favor of abandoning the Sage distribution (despite the fact that I have certainly put a lot of time and energy into it) **if** it is determined that the user community is sufficiently served by conda-forge packaging.
> But I think that this would require for more developers to engage with the conda-related issues (example: https://github.com/sagemath/sage/issues/35528).

This can be done if we drop the ballast, not any other way.

No. Abandoning the Sage distribution would be done in 1 shot.

Doing it 1 package at a time makes no sense.

As I explained (cut away in quote), ""The big problem is that the middle ground between "Complete Sage distribution that works in most use cases" and "No Sage distribution" is worse than both of the extremes. By removing spkgs one by one, we would make the Sage distribution less useful. So this is not a meaningful process."""

[Matthias Koeppe]

On Wednesday, April 26, 2023 at 1:46:41 PM UTC-7 Dima Pasechnik wrote:

we can barely keep up with security updates for e.g. openssl. It
took Thierry to provide a patch today, and me converting it into a PR,
else we probably would be still shipping openssl version with severe
CVEs.

You know as well as I do that

-  this update is done with the single command "./sage -package update openssl 3.0.5 --commit".

- openssl is not used in any security-relevant way in Sage. (I will not discuss this further.)

[Matthias Koeppe]

Right, each of these was separately and concretely substantiated with facts.

- tar was dropped after it was found that on all supported platforms, the standard system tar did the job.

- R/rpy2, as I just explained in a message above.

For context for the general readership of this list: 

gcc/gfortran/python3 are directly tied to what platform support we can claim (note that gcc/gfortran are the same package except for how the scripts are called).

I document this platform support in the release tours (see https://github.com/sagemath/sage/wiki/Sage-9.8-Release-Tour#sources) based on the tests that run on GH Actions. Changes to platform support of the Sage distribution are tracked in https://github.com/sagemath/sage/issues/32074

[John H Palmieri]

In an attempt to make this less of a religious war and more akin to something like a rational discussion:

- The status quo is that we include Python3 and gcc. If you want to argue for their removal, you need to provide evidence that this will not cause problems for people on supported platforms. What's the evidence? In addition, what sort of evidence would convince you to change your mind and admit that these packages need to be kept for a while longer?

- On the other side of the coin, if you have opposed removing these packages, what sort of evidence would convince you to change your mind and admit that these packages can be removed from the Sage distribution?

[Michael Orlitzky]

On Wed, 2023-04-26 at 13:06 -0700, Matthias Koeppe wrote:
>
> 2. I'm not in favor of chipping away 1 package at a time in the name
> of unsubstantiated, vague notions that a package is "ballast slowing
> down Sage's progress".
>

There's a ticket open to update PARI within Sage. First, upstream had
to release the new version. So far, at least three sage developers have
worked on it. The update includes a backported patch, a test for the
patch, and configure checks for the patch. So, once the update makes
its way into sage, every distribution maintainer is going to have to
backport the same patch into their version of PARI. Except the sage
patch doesn't include the fix to the test suite. So the source based
distributions are also going to have to separately backport the fix for
the test suites. There are 12 distros listed in build/pari/distros, so
at least 12 people this will affect.

How many people will it take how many hours to complete this trivial
upgrade? These are not vague notions.

Dropping one package at a time has two major benefits:

1. Not all sage packages are available in all distros. Eliminating 
the easy ones like gcc and python makes it possible to focus on 
the ones that pose real problems.

2. The sage library and test suites are coupled much too tightly to 
dependencies like PARI and maxima. Piggybacking off the earlier
example, distroless Sage cannot continue to test for patches that
exist only in upstream git head. We should also endeavour to make
our tests independent of the particular string representation that
e.g. maxima uses. There are lots of tests that work only with one
specific version of maxima because the answers look different,
rather than because they are fundamentally unequal. Fixing all of 
these issues will take a lot of time and work. It will only be
feasible to fix them if we do it a little bit at a time. We should 
fix them anyway because updating the tests every time a new maxima 
is released is a waste of time. But we must fix them if we expect 
the distro maxima to work.

[Matthias Koeppe]

Thanks, John. But I think it's more productive to ask:

**What was/is/will be the *purpose* of maintaining the Sage distribution?**

(Historically; as of today; and looking forward by a year or two.)

Here are some of my thoughts on this question:

1. Ease of installation.

Historically, an important purpose was to make loads of software packages, including many poorly maintained math software, easy to install.

In particular -- easy to install for a user on a shared machine ("big department compute server") without root access.

And in particular -- on shared machines with long outdated distributions ("Department IT installed it when the machine was bought, 10 years ago.")

As of today, it is plausible that such situations still exist. There are definitely still "shared compute server" situations (in particular, HPC clusters) where users cannot use container technology such as Docker and lxc, and therefore cannot use Linux distribution packaging solutions (archlinux, debian, ...). Overall I don't think we have sufficient insights about our worldwide user base to be sure. Here the Sage distribution still may have a value for users. Another option is non-root installable packaging: essentially, conda-forge (although nix and guix may be other options). But as I wrote earlier, there are still loose ends regarding Sage development in a pure conda environment (note that it is still marked as "experimental" in https://doc.sagemath.org/html/en/installation/conda.html#using-conda-to-provide-all-dependencies-for-the-sage-library-experimental), and also optional packages are missing.

Going forward, if the loose ends are ironed out (I'm mixing metaphors for comical effect) and missing packages added, I think that Sage installation, use, and development can be fully supported on top of conda-forge. This takes engagement and work; and this could certainly be done faster if a decision to abandon the Sage distribution on a specific release / date is made, because then substantial resources are freed. A time frame of a year or two could be realistic.

(I am also working on another deployment path using Python wheels, but this is much more work than just fixing the remaining conda-forge problems.)

2. Control of dependencies and the "many upstreams - many downstreams" problem.

For Sage developers, the Sage distribution is a way to have direct control over all dependencies -- that's the Sage distribution's role as a "reference distribution". 

(This role has been weakened since we introduced the spkg-configure mechanism of working with system packages, of course. This is an activity that does make sense one package at a time, but details such as how strict we are in what we accept from the system matter; see Michael's thoughts in his message.)

But still the following points apply:

a) If a critical bug is discovered, we can patch it and don't have to rely on people and infrastructure "outside the project" to fix things for us. 

Of course, we have been very lucky that packagers for many distributions have been consistently highly engaged with the project; but this is not something that we can take for granted. 

b) And, of course, more Sage developers can become contributors to the packaging communities; but there is the real danger that taking care of both upstream development *and* downstream packaging for the same project can lead to developer burnout. 

c) There is a danger that our project's endorsing of a particular packaging solution (e.g. conda-forge) could alienate highly engaged packagers for other systems. And if left unchecked, it could also lead to the re-introduction of code that is too tightly coupled with the specifics of conda-forge packaging.

[Matthias Koeppe]

I've reposted this last message in a separate thread.

[Matthias Koeppe]

Michael, do you happen to have a suggestion what version range of PARI the Sage library should be supporting?

[Michael Orlitzky]

On 2023-04-26 18:38:32, Matthias Koeppe wrote:
> Michael, do you happen to have a suggestion what version range of PARI the
> Sage library should be supporting?

PARI doesn't strictly follow semver, so whatever I say here, PARI will
eventually make a fool of me. Still, I think a fair goal is to support
the latest "point" release series, currently 2.15.x.

My comment is about the approach we take to version compatibility
moreso than a hard rule to be followed. For example,

* We should not be outlawing minor versions of packages for bugs
that have been fixed upstream,
* We should not be reproducing in sagelib any tests that are part
of an upstream package,
* We should avoid string equality where possible in sagelib tests,

In other words,

* We should not be going out of our way to break compatibility.

That alone will go quite far, and whatever it gets us is acceptable.

[Matthias Koeppe]

On Wednesday, April 26, 2023 at 7:37:17 PM UTC-7 Michael Orlitzky wrote:

On 2023-04-26 18:38:32, Matthias Koeppe wrote:
> Michael, do you happen to have a suggestion what version range of PARI the
> Sage library should be supporting?

PARI doesn't strictly follow semver, so whatever I say here, PARI will
eventually make a fool of me.

I agree, it's a hard question.

 

Still, I think a fair goal is to support
the latest "point" release series, currently 2.15.x.

Just as a data point, eliminating the spkg and only supporting system PARI 2.15.x would have the effect to eliminate support of:

- all versions of Ubuntu except for 23.04 (lunar); 

- all openSUSE Leap versions, leaving only the rolling distro (Tumbleweed).

Source: https://repology.org/project/pari/versions

 

My comment is about the approach we take to version compatibility
moreso than a hard rule to be followed. For example,

* We should not be outlawing minor versions of packages for bugs
that have been fixed upstream,
* We should not be reproducing in sagelib any tests that are part
of an upstream package,
* We should avoid string equality where possible in sagelib tests,

In other words,

* We should not be going out of our way to break compatibility.

That alone will go quite far, and whatever it gets us is acceptable.

All this sounds very reasonable, of course.

A problem that remains is how we would manage user expectations when they report a bug to us that turns out to be an upstream bug in a package that we no longer carry as an spkg: We would no longer be able to say "it's fixed in Sage 10.7" but instead would have to say "not the fault of Sage; just go upgrade your Linux distro to the unstable release / ask your distro to backport the bugfix / compile the package yourself from source".

 

[William Stein]

On Wed, Apr 26, 2023 at 7:59 PM Matthias Koeppe <matthia...@gmail.com> wrote:

On Wednesday, April 26, 2023 at 7:37:17 PM UTC-7 Michael Orlitzky wrote:

On 2023-04-26 18:38:32, Matthias Koeppe wrote:
> Michael, do you happen to have a suggestion what version range of PARI the
> Sage library should be supporting?

PARI doesn't strictly follow semver, so whatever I say here, PARI will
eventually make a fool of me.

I agree, it's a hard question.

 

Still, I think a fair goal is to support
the latest "point" release series, currently 2.15.x.

Just as a data point, eliminating the spkg and only supporting system PARI 2.15.x would have the effect to eliminate support of:

- all versions of Ubuntu except for 23.04 (lunar); 

- all openSUSE Leap versions, leaving only the rolling distro (Tumbleweed).

Source: https://repology.org/project/pari/versions

 

What if you want to install on other Ubuntu versions, but via mamba/conda/whatever?

My comment is about the approach we take to version compatibility
moreso than a hard rule to be followed. For example,

* We should not be outlawing minor versions of packages for bugs
that have been fixed upstream,
* We should not be reproducing in sagelib any tests that are part
of an upstream package,
* We should avoid string equality where possible in sagelib tests,

In other words,

* We should not be going out of our way to break compatibility.

That alone will go quite far, and whatever it gets us is acceptable.

All this sounds very reasonable, of course.

A problem that remains is how we would manage user expectations when they report a bug to us that turns out to be an upstream bug in a package that we no longer carry as an spkg: We would no longer be able to say "it's fixed in Sage 10.7" but instead would have to say "not the fault of Sage; just go upgrade your Linux distro to the unstable release / ask your distro to backport the bugfix / compile the package yourself from source".

 

--

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

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/3c05b1b8-f8e3-4fb1-b39e-f296e5efd40bn%40googlegroups.com.

--

-- William Stein

[Matthias Koeppe]

On Wednesday, April 26, 2023 at 8:40:08 PM UTC-7 William Stein wrote:

On Wed, Apr 26, 2023 at 7:59 PM Matthias Koeppe <matthia...@gmail.com> wrote:

Just as a data point, eliminating the spkg and only supporting system PARI 2.15.x would have the effect to eliminate support of:

- all versions of Ubuntu except for 23.04 (lunar); 

- all openSUSE Leap versions, leaving only the rolling distro (Tumbleweed).

Source: https://repology.org/project/pari/versions

 

What if you want to install on other Ubuntu versions, but via mamba/conda/whatever?

When conda-forge is in use, all packages (including compilers etc.) should come from conda-forge; then the distribution does not matter. Trying to mix OS distribution packages with conda packages is likely not a good idea.

 

[Michael Orlitzky]

On 2023-04-26 19:59:01, Matthias Koeppe wrote:
> On Wednesday, April 26, 2023 at 7:37:17 PM UTC-7 Michael Orlitzky wrote:
>
> Just as a data point, eliminating the spkg and only supporting system PARI
> 2.15.x would have the effect to eliminate support of:
> - all versions of Ubuntu except for 23.04 (lunar);
> - all openSUSE Leap versions, leaving only the rolling distro (Tumbleweed).
> Source: https://repology.org/project/pari/versions

It would be better if we could support the last minor version of PARI
as well, but I'm not volunteering anyone else's time to do it. If we
adopt a more flexible approach in sagelib, we'll sometimes get lucky:
there just won't be any breakage between minor versions, or it will be
trivial to support both. But yes, there will eventually be some change
that forces us to say "upgrade your PARI, or use an older version of
sage."

It's not the end of the world if users on a distro with old
dependencies have to stick to an older version of sage. Ideally, they
would be getting sage from their distro in the first place. A problem
only arises when you try to build a bleeding-edge sage on an older
stable distro -- an undertaking unsupported by most projects. Anyone
bothered by this can of course send us patches that extend
compatibility to older PARI. The burden of universal support would
however be transferred from the sage developers to the distros where
it rightfully lies.

> All this sounds very reasonable, of course.
>
> A problem that remains is how we would manage user expectations when they
> report a bug to us that turns out to be an upstream bug in a package that
> we no longer carry as an spkg: We would no longer be able to say "it's
> fixed in Sage 10.7" but instead would have to say "not the fault of Sage;
> just go upgrade your Linux distro to the unstable release / ask your distro
> to backport the bugfix / compile the package yourself from source".

That exact response is standard. It's a bit less friendly but a lot
more sensible.

[Nils Bruin]

On Thursday, 27 April 2023 at 03:59:22 UTC-7 Michael Orlitzky wrote:

It's not the end of the world if users on a distro with old
dependencies have to stick to an older version of sage. Ideally, they
would be getting sage from their distro in the first place. A problem
only arises when you try to build a bleeding-edge sage on an older
stable distro -- an undertaking unsupported by most projects. Anyone
bothered by this can of course send us patches that extend
compatibility to older PARI. The burden of universal support would
however be transferred from the sage developers to the distros where
it rightfully lies.

It may be that the situation about packaging math software has genuinely improved; in which case this likely thanks to sage: it took a whole bunch of math software, made it so that it could build in a coherently working whole, raised the profile to such a level that people with good connections to distributions stood up willing to support it as package distributions.

But another problem before was that the different packages would not develop in lockstep. Some components might need one specific version of prerequisites and others another. So one could run into genuine version conflicts. Sagemath was in a position to then resolve to conflict in the best way *for sage*. It's not clear to me that distributions, that have to serve other interests as well, will be able to do the same. It's also not entirely clear to me that distribution maintainers will always be able to catch erroneous behaviour due to mismatched components. So that's where sage-the-distribution still serves as an insurance policy -- something to fall back on when the version requirements make it impossible to run a set of packages together on a system-wide distribution.

it may be an option to provide a reference VM/docker image rather than a "sage-the-distribution" if that is easier to maintain, but at the moment, since we're not providing that, it would be more work.

[Michael Orlitzky]

On Thu, 2023-04-27 at 08:38 -0700, Nils Bruin wrote:
>
> But another problem before was that the different packages would not
> develop in lockstep. Some components might need one specific version of
> prerequisites and others another. So one could run into genuine version
> conflicts.

In theory this is a problem with every package. But in practice, we've
got 20,000 of them and few major conflicts. Solving this is what a
linux distribution does, and it's OK to punt the problem to them.

Personally I'm not getting out of any work here, since I'm also working
on the distro packages. Making Sage more lenient would however be a
valuable use of my time, in contrast with the current approach.

[Matthias Koeppe]

On Thursday, April 27, 2023 at 3:59:22 AM UTC-7 Michael Orlitzky wrote:

On 2023-04-26 19:59:01, Matthias Koeppe wrote:
> Just as a data point, eliminating the spkg and only supporting system PARI
> 2.15.x would have the effect to eliminate support of:
> - all versions of Ubuntu except for 23.04 (lunar);
> - all openSUSE Leap versions, leaving only the rolling distro (Tumbleweed).
> Source: https://repology.org/project/pari/versions

It would be better if we could support the last minor version of PARI
as well, but I'm not volunteering anyone else's time to do it. If we
adopt a more flexible approach in sagelib, we'll sometimes get lucky:
there just won't be any breakage between minor versions, or it will be
trivial to support both. But yes, there will eventually be some change
that forces us to say "upgrade your PARI, or use an older version of
sage."

It's not the end of the world if users on a distro with old
dependencies have to stick to an older version of sage. Ideally, they
would be getting sage from their distro in the first place. A problem
only arises when you try to build a bleeding-edge sage on an older
stable distro -- an undertaking unsupported by most projects.

Is it? I would say that Sage is very special in this regard because of its extreme number of complicated dependencies; and because of its long-standing goals of empowering the members of the user community to become contributors.

For example, people can contribute to sympy, numpy, scipy etc. on a very wide range of systems (pretty much the same that we currently support in the Sage distribution because we recently tightened our compiler requirements based on scipy's needs).

And we know that development against an old version of Sage is not practical; we always recommend to people to start from the latest beta for development. 

But this creates a serious barrier: If Sage development can only be done on bleeding-edge distributions, new Sage developers need to abandon their current distribution. That's really bad.

Anyone
bothered by this can of course send us patches that extend
compatibility to older PARI.

Would we welcome such patches? When we upgrade a package such as PARI, typically very experienced Sage developers have already assessed how easy it would be to keep the old version supported. When it is decided to drop support, it is often not because we don't know how to support both but rather because we do not want to have more complicated code in Sage.

[Michael Orlitzky]

On Thu, 2023-04-27 at 12:37 -0700, Matthias Koeppe wrote:
> A problem only arises when you try to build a bleeding-edge sage on an older
> stable distro -- an undertaking unsupported by most projects.
>
> Is it? I would say that Sage is very special in this regard because of its
> extreme number of complicated dependencies; and because of its
> long-standing goals of empowering the members of the user community to
> become contributors.

"Unsupported" was too strong, but a lot of large projects expect a
higher level of sophistication from developers than users. For example,
you're expected to have the latest GNUlib or autotools installed, or
perhaps the latest LLVM, and a concoction of obscure test-suite
dependencies. Gentoo stable is still on openssl-1.1, and I've had to
put 3.x in /usr/local a few times to build projects that got tired of
adding #ifdefs.

This does... interact... with the goal of making it easy to contribute.
But the complexity of the sage distribution and build system also makes
it harder to use and develop sage.

> But this creates a serious barrier: If Sage development can only be done on
> bleeding-edge distributions, new Sage developers need to abandon their
> current distribution. That's really bad.

I agree, and "unsupported" carried the wrong connotation. You can
certainly develop on those distros, but you're responsible for
obtaining the dependencies. You can find them in a third-party rpm/deb
repo, or build them in /usr/local, or install them with Nix/Conda/Guix.

How difficult this is depends on how deeply the dependency is embedded
in the tree. You know this, but for the sake of the list: you can't
build only a local copy of PARI, you have to build local copies of
anything else that will be linked to both PARI and sage. Otherwise
it'll crash when you load both PARIs into the same process. In
contrast, a python package at the edge of the graph can be installed
locally with only a "pip install".

We should take that into account when deciding how important backwards-
compatibility is for a given package; there's no silver bullet.

> Anyone bothered by this can of course send us patches that extend
> compatibility to older PARI.
>
> Would we welcome such patches? When we upgrade a package such as PARI,
> typically very experienced Sage developers have already assessed how easy
> it would be to keep the old version supported. When it is decided to drop
> support, it is often not because we don't know how to support both but
> rather because we do not want to have more complicated code in Sage.

We would have to take into account that breaking compatibility will
force people on old distros to build local copies of not only pari, but
also lcalc, giac, eclib, etc. Cleaning out the sage test suite will
help some, but we will inevitably spend more time on compatibility than
we do now.

I think it's a better use of our time though. We'll be spending time
making sure it works out of the box, rather than spending time on the
fallback that we have to use because it doesn't work out of the box.

[Thierry]

Hi,

Le Wed, Apr 26, 2023 at 10:43:35AM +0100, Dima Pasechnik a écrit :
> Thanks, it's now https://github.com/sagemath/sage/pull/35571

Could this straightforward ticket be set to blocker and reviewed for the
next official release ?

Ciao,
Thierry


>
> On Wed, Apr 26, 2023 at 10:32 AM Thierry
> <sage-goo...@lma.metelu.net> wrote:
> >
> > Hi,
> >
> > Sage's current openssl version (3.0.5) hass several "High severity"
> > vulnerabilities, see https://www.openssl.org/news/vulnerabilities.html
> >
> > It would be nice to have the fixes included in the next Sage release. I am not
> > using github, here is a pull request (literally) to fix this :
> >
> > git pull https://lipn.univ-paris13.fr/~monteil/hebergement/sage/sage.git openssl.3.0.8
> >
> > (commit hash : 997a6bd35a17f5511bb12552bd676597b09f1eaf)
> > I checked the hash of the tarballs against the GPG signatures by upstream developers.
> >
> > Tarball at : https://www.openssl.org/source/openssl-3.0.8.tar.gz
> >
> > Ciao,
> > Thierry
> >
> > P.S. Note that 3.1.0. has been very recently released, however 3.0.x is LTS and will
> > not have structural changes. Just in case, here is a verified branch :
> >
> > git pull https://lipn.univ-paris13.fr/~monteil/hebergement/sage/sage.git openssl.3.1.0
> >
> > (commit hash : 9229a2be66dc0e4f2e3f677aa515a33bfe72a873)
> > Tarball at : https://www.openssl.org/source/openssl-3.1.0.tar.gz
> >
> >
> >
> >
> > Le Sun, Apr 23, 2023 at 07:46:00AM -0700, Volker Braun a écrit :
> > > 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
> > >
> > >
> > > f3acd42678a (tag: 10.0.rc0, github/develop) Updated SageMath version to
> > > 10.0.rc0
> > > eca2a773d08 gh-35543: Cleaning set partition
> > > 9d8c9c05117 gh-35542: some fixes for cython-lint in various places
> > > e1e119463ae gh-35534: some cython-lint fixes in matroids/
> > > 133a345bacb gh-35533: Fix bug in graph.maximum_average_degree
> > > 3c2ba826156 gh-35530: some minor details in interfaces
> > > 12cea800735 gh-35526: fix pycodestyle E271 and E502 in pyx files
> > > a03f09cf594 gh-35525: cython-lint and some doc cleanup for expression.pyx
> > > e9b67cc117a gh-35521: `sage.combinat.sf`: re-enable a doctest
> > > cc0ea4d66f4 gh-35518: Improve PolynomialSequence.connected_components()
> > > a38a25a261e gh-35515: Bug in integer valued polys
> > > 803c7aacaee gh-35514: Don't force ecl lisp with `maxima -l ecl` on command
> > > line.
> > > 20d2edd1736 gh-35513: Silence initialization of giac
> > > 64c205c7d51 gh-35512: Improve PolynomialSequence.connection_graph()
> > > implementation
> > > db2fa5d13b1 gh-35511: Fix Graph.add_clique() for one vertex
> > > 0ff23f67772 gh-35510: Make BooleanPolynomial.variables() way faster
> > > e3636bd579c gh-35509: some cython-linting in matrix/ folder
> > > 2c7e16e5faf gh-35507: fix pycodestyle E303 in schemes
> > > 98595ef8661 gh-35506: add check for pycodestyle E502 in python files
> > > 80f3fd99d04 gh-35504: `build/pkgs/sphinx_{copybutton,basic_ng}`: Add conda
> > > info
> > > 41c256ae647 gh-35499: Fix test output for ipywidgets 8.0.5, part deux
> > > 3740e145432 gh-35478: Remove unused code from GAP interface
> > > b25229b6647 gh-35476: scipy: Patch out test requiring internet access
> > > eafd5215a28 gh-35472: Implement the Feichtner-Yuzvinsky rings for lattices
> > > 957e627f023 gh-35465: Fix conda workflow
> > > 1fc3fee5bed gh-35463: Add iterator over minimum distance k dominating sets
> > > ecd162be3dc gh-35462: Iterator over the minimal distance k dominating sets
> > > c18a3fbfe72 gh-35446: add method is_simple to permutations
> > > ef68bee7ccf gh-35443: Fix slow doctests or mark # long time
> > > c005c006d4e gh-35431: Documentation improvements for rounding methods
> > > 15a5078afaa gh-35389: `sage.rings.finite_rings.residue_field`:
> > > Modularization fixes
> > > 9ff469adb9c gh-35375: Fix minimal kernel basis corner cases
> > > 55ebb79b65a gh-35306: `sage.groups.matrix_gps`: Modularization fixes for
> > > imports
> > > 8bcce63b6a1 gh-35305: `sage.quadratic_forms`: Modularization fixes for
> > > imports
> > > 97b45d80a7c (tag: 10.0.beta9) Updated SageMath version to 10.0.beta9
> > >
> > > --
> > > 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/788f2bad-420b-463a-be98-4f11819d3288n%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 on the web visit https://groups.google.com/d/msgid/sage-release/ZEjvpybhNZhFERjm%40metelu.net.
>
> --
> 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/CAAWYfq346afEF1dUqJuJ4ZGuznH-Bs7UH%2BrxkBpvu1zFYwVjqQ%40mail.gmail.com.