Re: What to do about sagemath
On Wed, Oct 17, 2018 at 11:35 AM Paulo César Pereira de Andrade
wrote:
> I am afraid I did not help with sagemath for quite some time, and
> would really like to
> thank Jerry for keeping working on it.
HI Paulo. It's good to hear from you! I hope you are well.
I think I'm past the cython problems now. There are a few more issues
to fix, but I think I made a lot of progress over the last few days.
Unfortunately, I now have to drop the ball and do some traveling for
the rest of this week. I'll try to move forward again next Monday,
but until then, if anybody feels motivated to work on the remaining
issues, I'll attach what I have so far (modified spec file and a few
new patches).
There are still a handful of python 3 incompatibilities to solve, and
I see no less than 4 segfaults during the doctest runs. It would be
good to figure out what is causing those.
Regards,
--
Jerry James
http://www.jamezone.org/
%global __provides_exclude_from .*/site-packages/.*\\.so
# This package installs python files in nonstandard places
%global _python_bytecompile_extra 0
%bcond_with bundled_pexpect
%bcond_with bundled_ipython
%bcond_without bundled_ipywidgets
%bcond_without bundled_thebe
%bcond_without bundled_threejs
%bcond_without bundled_widgetsnbextension
%bcond_without install_hack
# for faster full rpm test builds
%ifarch %{ix86} x86_64
%bcond_without docs
%else
%bcond_with docs
%endif
# not functional due to missing jar dependencies
%bcond_with sage3d
# use an workaround to match upstream sagemath patched sphinx
%bcond_without sphinx_hack
# use workaround to match upstream sagemath patched cython
%bcond_with cython_hack
%ifarch x86_64
%bcond_without fes
%else
%bcond_with fes
%endif
# switch to run make -testall
%bcond_with check
%global SAGE_TIMEOUT 60
%global SAGE_TIMEOUT_LONG 180
%global combinatorial_designs_pkg combinatorial_designs-20140630
%global conway_polynomials_pkg conway_polynomials-0.5
%global elliptic_curves_pkg elliptic_curves-0.8
%global flintqs_pkg flintqs-1.0
%global graphs_pkg graphs-20161026
%if %{with bundled_ipython}
%global ipython_pkg ipython-5.5.0
%endif
%if %{with bundled_ipywidgets}
%global ipywidgets_pkg ipywidgets-7.2.0
%endif
%if %{with bundled_pexpect}
%global pexpect_pkg pexpect-4.1.0
%endif
%global polytopes_db_pkg polytopes_db-20170220
%global rubiks_pkg rubiks-20070912
%global sagenb_pkg sagenb-1.0.3
%global sagenb_export_pkg sagenb_export-3.2
%global sagetex_pkg sagetex-3.0
%global Sphinx_pkg Sphinx-1.7.5
%global singular_pkg singular-4.1.0p3
%if %{with bundled_thebe}
%global thebe_pkg thebe-9624e0a0
%endif
%if %{with bundled_threejs}
%global threejs_pkg threejs-r80
%endif
%if %{with bundled_widgetsnbextension}
%global widgetsnbextension_pkg widgetsnbextension-3.2.0
%endif
# Spkg equivalents of required rpms; we pretend they are installed as spkgs.
# The version numbers shown are those of the latest released spkg, if the Fedora
# version is not behind.
%global SAGE_REQUIRED_PKGS 4ti2-1.6.7 cbc-2.9.4 CoCoALib-0.99564 cryptominisat-5.0.1 gap_packages-4.8.6new2 gmp-6.1.2 gmpy2-2.1.0a1 lrslib-062+autotools-2017-03-03 qepcad-B.1.69 saclib-2.2.6 surf-1.0.6-gcc6
%global SAGE_ROOT %{_libdir}/sagemath
%global SAGE_LOCAL %{SAGE_ROOT}/local
%global SAGE_SRC %{SAGE_ROOT}/src
%global SAGE_DOC %{_docdir}/%{name}
%global SAGE_SHARE %{_datadir}/sagemath
%global SAGE_ETC %{SAGE_SHARE}/etc
%global SAGE_PYTHONPATH %{SAGE_ROOT}/site-packages
%global SAGE_SPKG_INST %{SAGE_LOCAL}/var/lib/sage/installed
Name: sagemath
Summary: A free open-source mathematics software system
Version: 8.3
Release: 2%{?dist}
# The file ${SAGE_ROOT}/COPYING.txt is the upstream license breakdown file
# Additionally, every $files section has a comment with the license name
# before files with that license
License: ASL 2.0 and BSD and GPL+ and GPLv2+ and LGPLv2+ and MIT and Public Domain
URL: http://www.sagemath.org
Source0: http://files.sagemath.org/src/sage-%{version}.tar.gz
Source1: gprc.expect
# Follow maxima's ExclusiveArch
ExclusiveArch: aarch64 %{arm} %{ix86} x86_64 ppc sparcv9
# Upstream uses mpir not gmp, but the rpm package is tailored to use gmp
Patch1: %{name}-gmp.patch
# Set of patches to work with system wide packages
Patch2: %{name}-scripts.patch
# remove call to not implemented sagemath "is_package_installed" interfaces
# need to package coin-or solver in fedora
# remove check for non free solvers
Patch3: %{name}-extensions.patch
# helper to:
# o respect a DESTDIR environment variable
# o avoid double '//' in pathnames, what can confused debugedit & co
# o minor change to help in incremental builds by avoiding rebuilding
# files
# o do not assume there is an installed sagemath
Patch4: %{name}-rpmbuild.patch
# build documentation in buildroot environment
Patch5: %{name}-sagedoc.patch
# sage notebook rpm and system environment adjustments
Patch6: %{name}-sagenb.patch
# do not attempt to create state files in system directories
Patch7:
Re: What to do about sagemath
%buEm ter, 16 de out de 2018 às 15:05, Miro Hrončok escreveu: > > On 16.10.2018 19:17, Jerry James wrote: > > On Tue, Oct 16, 2018 at 9:51 AM Jerry James wrote: > >> Sadly, no. > > > > Here is the challenge, Python aficionados. The attached file, > > test.pyx, can be processed like this on Fedora 28 with Cython 0.28.4: > > "cythonize -3 test.pyx". That succeeds and generates code that Does > > The Right Thing. > > > > On Rawhide with Cython 0.29rc2, that fails as noted earlier in this > > thread. The name PyLongObject cannot be imported with cimport. How > > does the code need to change to compute the same result? > > This compiles for me: > > from cpython.longintrepr cimport PyLong_SHIFT, py_long, digit > ... > cdef const digit* D = (x).ob_digit I am afraid I did not help with sagemath for quite some time, and would really like to thank Jerry for keeping working on it. The big problem with sagemath is that they gave up on having patches accepted by several different upstream projects long ago. After giving up on getting patches everywhere, they eventually started adding all kinds of patches to lots of packages, and one might even need their version of gcc/g++ to build. At some point it was required to build a custom cython in the buildroot, and use it. Currently there is the cython_hack bcond. The problem of using a custom cython in the buildroot is that a minor set of functionality would be lost after install due to incompatible cython. I am afraid I would suggest temporarily adding a '%bcond_without bundled_cython', and using a custom cython build *until* a compatible cython is available in rawhide/ otherwise, it breaks in a way that would be way too complex to recover from :( I am still around, just that could not get back on having enough free time for volunteer work in Fedora for several months in a row :( But I hope it will change soon. Thanks! Paulo ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What to do about sagemath
On 16.10.2018 19:17, Jerry James wrote: On Tue, Oct 16, 2018 at 9:51 AM Jerry James wrote: Sadly, no. Here is the challenge, Python aficionados. The attached file, test.pyx, can be processed like this on Fedora 28 with Cython 0.28.4: "cythonize -3 test.pyx". That succeeds and generates code that Does The Right Thing. On Rawhide with Cython 0.29rc2, that fails as noted earlier in this thread. The name PyLongObject cannot be imported with cimport. How does the code need to change to compute the same result? This compiles for me: from cpython.longintrepr cimport PyLong_SHIFT, py_long, digit ... cdef const digit* D = (x).ob_digit -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What to do about sagemath
On Tue, Oct 16, 2018 at 11:17 AM Jerry James wrote: > On Rawhide with Cython 0.29rc2, that fails as noted earlier in this > thread. The name PyLongObject cannot be imported with cimport. How > does the code need to change to compute the same result? I should have tried figuring this out for just a few more minutes prior to sending that email. It looks like we need to cimport the name py_long, and arrange for Python to know that x has type py_long. At that point, x.ob_digit becomes valid. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What to do about sagemath
On Tue, Oct 16, 2018 at 9:51 AM Jerry James wrote: > Sadly, no. Here is the challenge, Python aficionados. The attached file, test.pyx, can be processed like this on Fedora 28 with Cython 0.28.4: "cythonize -3 test.pyx". That succeeds and generates code that Does The Right Thing. On Rawhide with Cython 0.29rc2, that fails as noted earlier in this thread. The name PyLongObject cannot be imported with cimport. How does the code need to change to compute the same result? Thanks, -- Jerry James http://www.jamezone.org/ from cpython.object cimport Py_SIZE from cpython.longintrepr cimport PyLongObject, PyLong_SHIFT, digit cdef enum: ERR_TYPE = 1 ERR_INDEX = 2 ERR_OVERFLOW = 3 cdef inline long dig(const digit* D, int n): return (D[n]) << (n * PyLong_SHIFT) cdef bint do_stuff_to_a_long(x, long* value, int* err) except -1: cdef const digit* D = (x).ob_digit cdef Py_ssize_t size = Py_SIZE(x) cdef int BITS_IN_LONG = 8 * sizeof(long) - 1 cdef long lead cdef long lead_3_overflow = (1) << (BITS_IN_LONG - 2 * PyLong_SHIFT) if size == 0: value[0] = 0 err[0] = 0 elif size == 1: value[0] = dig(D, 0) err[0] = 0 elif size == -1: value[0] = -dig(D, 0) err[0] = 0 elif size == 2: value[0] = dig(D, 0) + dig(D, 1) err[0] = 0 elif size == -2: value[0] = -(dig(D, 0) + dig(D, 1)) err[0] = 0 elif size == 3: lead = D[2] if lead < lead_3_overflow: value[0] = dig(D, 0) + dig(D, 1) + dig(D, 2) err[0] = 0 else: err[0] = ERR_OVERFLOW elif size == -3: lead = D[2] if lead < lead_3_overflow: value[0] = -(dig(D, 0) + dig(D, 1) + dig(D, 2)) err[0] = 0 elif D[0] == 0 and D[1] == 0 and lead == lead_3_overflow: # Special case for LONG_MIN value[0] = (-1) << BITS_IN_LONG err[0] = 0 else: err[0] = ERR_OVERFLOW else: # 4 digits or more: guaranteed overflow err[0] = ERR_OVERFLOW return 1 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What to do about sagemath
On Sat, Oct 13, 2018 at 1:36 PM Miro Hrončok wrote: > Would changing to: > > cdef const digit* D = x.ob_digit > > do? Sadly, no. Error compiling Cython file: ... return 1 err[0] = ERR_TYPE return 0 # x is a Python "long" (called "int" on Python 3) cdef const digit* D = x.ob_digit ^ sage/arith/long.pxd:211:27: Cannot convert Python object to 'const digit *' I see references to PyLongObject in other Cythonized files, so Cython does "know about" this type in some sense. Further suggestions welcome. Regards, -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What to do about sagemath
On 12.10.2018 22:13, Jerry James wrote: This is from Includes/cpython/longintrepr.pxd in Cython 0.28.4, which does not trigger the above error: ctypedef struct PyLongObject: digit* ob_digit This is from the same file in Cython 0.29~rc2-1, which does trigger the above error: ctypedef class __builtin__.py_long [object PyLongObject]: cdef digit* ob_digit This was done in https://github.com/cython/cython/commit/4bd2c9b85ac2d85fe40a56296dcc86f271313c11 Particularly interesting is the change in tests/run/longintrepr.pyx: ret = _PyLong_New(index + 1) - (ret).ob_digit[index] = low + ret.ob_digit[index] = low There is exactly one use of PyLongObject, on line 211: cdef const digit* D = (x).ob_digit Would changing to: cdef const digit* D = x.ob_digit do? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What to do about sagemath
On Fri, Oct 5, 2018 at 2:48 AM Miro Hrončok wrote: > How can I help with the python3 transition? I need some help after all. Cythonizing of src/sage/arith/long.pxd is failing like so: Error compiling Cython file: ... from cpython.object cimport Py_SIZE from cpython.int cimport PyInt_AS_LONG from cpython.long cimport PyLong_AsLong from cpython.number cimport PyNumber_Index, PyIndex_Check from cpython.longintrepr cimport PyLongObject, PyLong_SHIFT, digit ^ sage/arith/long.pxd:22:0: 'cpython/longintrepr/PyLongObject.pxd' not found There is exactly one use of PyLongObject, on line 211: cdef const digit* D = (x).ob_digit This code is translating between gmp mpz_t objects and python integers. The error seems to be due to a change in cython, not in python itself. Still, I'm not sure how to fix the code so that cython will accept it. This is from Includes/cpython/longintrepr.pxd in Cython 0.28.4, which does not trigger the above error: ctypedef struct PyLongObject: digit* ob_digit This is from the same file in Cython 0.29~rc2-1, which does trigger the above error: ctypedef class __builtin__.py_long [object PyLongObject]: cdef digit* ob_digit If one of you python experts out there could tell me how the sagemath code needs to change to get access to x's ob_digit, I would appreciate it very much. Thank you, -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What to do about sagemath
On Fri, Oct 5, 2018 at 2:48 AM Miro Hrončok wrote: > How can I help with the python3 transition? Thanks for the offer, Miro. I don't know yet. I know that I'm going to have to make the build continue in spite of doctest failures. There are still quite a few of those. I'll try to work through the issues this weekend. If something pops up that you can help with, I will let you know. /me crosses fingers and hopes that upstream continues making good progress on the python 3 transition. Regards, -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What to do about sagemath
On 5.10.2018 04:56, Jerry James wrote: On Mon, Sep 24, 2018 at 7:58 AM Miro Hrončok wrote: IMHO You can build the python3 package as well, but blacklist it from the module. I'm starting to lean back towards migrating to the (experimental, buggy) python 3 build. Lots of python 3 fixes have gone into the (not quite released) sagemath 8.4. That would certainly be less work for me, since I wouldn't have to keep up with python 2 versions of various packages. That would be a good thing. I am soo far behind on Fedora work. My TODO list has never been so long before, so I think adding python 2 package maintenance onto the heap is not a great idea. I still haven't heard anything from Paulo. I don't know what his status is, but he seems to be absent for the time being, which means it's pretty much just me minding the sagemath store. The state of the packages will have to bow to my time pressure, unless somebody else steps up to help with maintenance, which hasn't happened yet. That was a roundabout way of saying, "I haven't figured out how modules work yet. I don't know when I will have time to figure it out, but probably not soon. Sagemath is already broken in Rawhide due to certain python 2 packages disappearing, so something has to be done, and this seems like the least work for me." :-) How can I help with the python3 transition? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What to do about sagemath
On Mon, Sep 24, 2018 at 7:58 AM Miro Hrončok wrote: > IMHO You can build the python3 package as well, but blacklist it from > the module. I'm starting to lean back towards migrating to the (experimental, buggy) python 3 build. Lots of python 3 fixes have gone into the (not quite released) sagemath 8.4. That would certainly be less work for me, since I wouldn't have to keep up with python 2 versions of various packages. That would be a good thing. I am soo far behind on Fedora work. My TODO list has never been so long before, so I think adding python 2 package maintenance onto the heap is not a great idea. I still haven't heard anything from Paulo. I don't know what his status is, but he seems to be absent for the time being, which means it's pretty much just me minding the sagemath store. The state of the packages will have to bow to my time pressure, unless somebody else steps up to help with maintenance, which hasn't happened yet. That was a roundabout way of saying, "I haven't figured out how modules work yet. I don't know when I will have time to figure it out, but probably not soon. Sagemath is already broken in Rawhide due to certain python 2 packages disappearing, so something has to be done, and this seems like the least work for me." :-) Regards, -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What to do about sagemath
On 24.9.2018 15:28, Owen Taylor wrote: Using modules for this purpose will take some care for parallel installability - unless you are happy with sagemath only being runnable from within a container. Unless I'm missing something, to restore a python2 subpackage that has been removed in the main Fedora, you'd need to: - Create a stream branch - Modify the spec file in that branch to *only* build the python2 subpackage IMHO You can build the python3 package as well, but blacklist it from the module. - Include that stream branch in your module -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What to do about sagemath
Using modules for this purpose will take some care for parallel installability - unless you are happy with sagemath only being runnable from within a container. Unless I'm missing something, to restore a python2 subpackage that has been removed in the main Fedora, you'd need to: - Create a stream branch - Modify the spec file in that branch to *only* build the python2 subpackage - Include that stream branch in your module Regards, Owen On Sun, Sep 23, 2018 at 12:07 AM Jerry James wrote: > On Sat, Sep 22, 2018 at 4:55 PM Miro Hrončok wrote: > > I never thought I would ever ask this, but would it make sense to get > > sagemath into a module? We could pin all the necessary python2 packages > > in the module to the current (or even older?) versions (and don't update > > them to newer versions that possibly drop py2 support). The rest of > > Fedora could move forward and sagemath would keep going on. > > H, that might make sense, at that. I have to admit now that I > haven't really been following the development of modules, and don't > really know how they work. I'll try to read up on them next week. > > Thanks for the suggestion. > -- > Jerry James > http://www.jamezone.org/ > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What to do about sagemath
On Sat, Sep 22, 2018 at 4:55 PM Miro Hrončok wrote: > I never thought I would ever ask this, but would it make sense to get > sagemath into a module? We could pin all the necessary python2 packages > in the module to the current (or even older?) versions (and don't update > them to newer versions that possibly drop py2 support). The rest of > Fedora could move forward and sagemath would keep going on. H, that might make sense, at that. I have to admit now that I haven't really been following the development of modules, and don't really know how they work. I'll try to read up on them next week. Thanks for the suggestion. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What to do about sagemath
On 22.9.2018 22:25, Jerry James wrote: On Fri, Sep 21, 2018 at 10:35 AM Charalampos Stratakis wrote: Only sagemath worries me in this list since AFAIK there is still some way to go, for full python3 support upstream. I wrote about this about a month ago, and then got super busy and didn't follow up. Sorry about that. But this is still an issue that needs to be tackled, one way or another. As I see it, we only have three viable options. 1. Somebody adopts the necessary python2 packages to keep sagemath going until upstream completes the python3 migration. There will be other problems. For example, rpy upstream dropped python2 support, so the latest rpy version (needed for the latest version of R) isn't available for python2. 2. We can switch sagemath over to the experimental python3 build. Lots of stuff is known to be broken in the python3 build. If upstream doesn't get things substantially working by the time of the Fedora 30 release, we should state clearly in the Fedora 30 release notes that sagemath users should not install or upgrade to that release. Then we'll have to cross our fingers and hope that sagemath upstream completes the transition by the time of Fedora 31. 3. Remove sagemath from Fedora. Tell sagemath users they will have to build it themselves from source. I don't have the bandwidth for #1. I'm stretched too thin already, and have been pondering what I can give up to better concentrate on the stuff I care about most. I am also facing spousal pressure to resign from Fedora package maintenance altogether. I sent Paulo an email at the beginning of this week, asking him what he wants to do. I have not heard back from him. I have not heard from him for months, actually, so I do not know what his status is. Bottom line: unless somebody else shows up soon willing to take on #1, we will be forced to go with #2 or #3. Frankly, #3 is probably better than fooling users into thinking that #2 is going to work. I never thought I would ever ask this, but would it make sense to get sagemath into a module? We could pin all the necessary python2 packages in the module to the current (or even older?) versions (and don't update them to newer versions that possibly drop py2 support). The rest of Fedora could move forward and sagemath would keep going on. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
