lrcalc: update to 2.1, rebuild sagemath-9.5

[tornaria]

This PR updates lrcalc to 2.1, which will be required for sagemath 9.6.

This needs that we rebuild sagemath 9.5 with a few changes:

• add a new python package python3-lrcalc
• patch sagemath 9.5 so it can use the new version of lrcalc (via python3-lrcalc)

Unrelated to that, I added two patches to sagemath which fix doctests after upgrades of ipython to 8.0 8.1 and scipy to 1.8.

[dkwo]

May I suggest that we split off a package like

sagemath-devel_package() { # or whatever you want to call it
 depends = "sagemath"
 depends += "move here all the -devel that is in sagemath depends, the compilers etc"
 desc += "development stuff, needed to pass all doctests, compile cython code etc."

Do you see any drawbacks?

[tornaria]

May I suggest that we split off a package like

sagemath-devel_package() { # or whatever you want to call it
 depends = "sagemath"
 depends += "move here all the -devel that is in sagemath depends, the compilers etc"
 desc += "development stuff, needed to pass all doctests, compile cython code etc."

Do you see any drawbacks?

What you suggest seems to ill-defined or at least very difficult to determine. What are some example packages that are now listed as runtime dependencies but you would move to sagemath-devel? What is the gain (say in installed-size) vs. what is to loose (as in what would stop working). If you are worried about download or installed size, we could have some sagemath-minimal which leaves out some functionality, e.g. some of the large databases. But the difference in size has to be worth it.

On a different note I was thinking to have a meta-package sagemath-builddeps which depends on all packages that are needed to build sagemath from the official source release (i.e. using all possible packages from system). This would not depend on sagemath, so it's a user choice to install from source.

I'm also working on a sagemath-beta package that will install current beta of sagemath -- the catch is that I want this to be installable side-by-side with the main sagemath package so we can test new releases as they come out.

In fact, the current PR (update of lrcalc) is motivated by this. In order to have sagemath and sagemath-beta installed at the same time we need both to use the same dependencies. Since sagemath-9.6.beta5 works only with lrcalc-2.1, we need to have sagemath-9.5 work with lrcalc-2.1 as well.

There are annoying doctest failures triggered by updates to python packages -- I thought I had all covered for the updates to ipython 8.0 and scipy 1.8 but it seems ipython 8.1 has another change. This is the failure we are seeing in CI, it should be easy to fix and push upstream if it's not already fixed in 9.6.beta5.

[dkwo]

I was thinking: depends="FlintQS eclib fflas-ffpack flintlib gd gfan giac gsl gzip libpng linbox m4ri maxima-ecl mpfr nauty ntl palp pari pari-elldata-small pari-galdata pari-galpol-small pari-seadata-small pkg-config python3-Cython python3-cypari2 python3-cysignals python3 python3-fpylll python3-ipython python3-lrcalc python3-ipython_ipykernel python3-jupyter_ipywidgets python3-matplotlib python3-memory_allocator python3-networkx python3-pip python3-pkgconfig python3-pplpy python3-primecountpy python3-requests python3-scipy python3-sympy python3-traitlets sage-data-combinatorial_designs sage-data-conway_polynomials sage-data-elliptic_curves sage-data-graphs sage-data-polytopes_db sympow tachyon" while depends+="eclib-devel flintlib-devel gcc-fortran gd-devel gsl-devel libpng-devel linbox-devel m4ri-devel mpfr-devel ntl-devel pari-devel python3-devel"

[tornaria]

depends+="eclib-devel flintlib-devel gcc-fortran gd-devel gsl-devel libpng-devel linbox-devel m4ri-devel mpfr-devel ntl-devel pari-devel python3-devel"

Granted, there are some large packages there. I'd like to have a look at what extent these are used in sage, etc. Ideally there should be a feature flag that indicates that a doctest only works when a working C compiler is installed, etc. That needs to be done with upstream.

What would happen to doctesting in CI? I guess that would still work since it's done in the masterdir...

Let me think about it... We need some good workflow to play with bare-bones void so we can test dependencies are ok, because an xbps-src chroot always contain gcc, etc. which will may not be installed (gcc is pulled in as a dependency of gcc-fortran).

[dkwo]

Ok, think about it.
I agree doctest in ci should still work.
Indeed, one can test with a different chroot, with only base installed.
This is the one I was using on musl
https://git.disroot.org/tuxliban/tutoriales_void/src/branch/master/Gu%C3%ADas/Container%20Void/Guide.md

[tornaria]

This was superseded by #36420, so I'm closing now.

The proposal to split a sagemath-devel subpkg seems useful, I will consider for sagemath-9.6.