Re: [sage-devel] Packaging Sage?

2020-05-10 Thread François Bissey
In sage-on-gentoo and some other distros (I think arch) I completely ignore
the meta packaging of sage. Every single packages is a system package.
and sage itself is built as a normal python package.
Because of problems with maintaining python2 compatibility, and keeping
around some packages compatible with python like sphinx is problematic,
I am now offering sage-9.1.rc2 as the default for sage-on-gentoo.
Details of the build and patches at
https://github.com/cschwan/sage-on-gentoo/tree/master/sci-mathematics/sage

François

> On 11/05/2020, at 1:02 AM, Thierry Thomas  wrote:
> 
> Hello,
> 
> TL;TR: Packagers, how do you deal with Sage to package it for your Linux
> distribution (or *BSD system)?
> 
> Details:
> 
> Sage has been ported to FreeBSD many years ago (4.8), but now the port
> is lagging and no more packages are built; I'm trying to fix it.
> 
> Problem: on FreeBSD, packages are built (by a porter or in the
> compilation farm) as a regular user, and installed in a staging
> directory (DESTDIR); then the package is installed as root in the final
> $PREFIX (ldconfig and so on are executed).
> 
> The naming may differ, but many packaging systems have a similar
> mechanism.
> 
> But Sage cannot be built with this method: the global install target is
> a no-op, and every sub-package is built and installed during the build
> target, under $SAGE_LOCAL, and everything is built relatively to this
> directory. If you try to move the resulting bits to another directory,
> it becomes unusable.
> 
> $SAGE_DESTDIR is handled, but does not solve this problem.
> 
> A first way to deal with it is to use as many system packages as
> possible (see #27330): Sage´s libraries built around a system package
> are safe.
> 
> For example, with the stock sage-9.1.rc3, when setting SAGE_LOCAL to my
> staging directory, these errors are emitted for cvxopt:
> 
> Error: 'lib/python3.7/site-packages/cvxopt/umfpack.so' is referring to 
> /usr/ports/math/sage/work/stage
> Error: 'lib/python3.7/site-packages/cvxopt/base.so' is referring to 
> /usr/ports/math/sage/work/stage
> Error: 'lib/python3.7/site-packages/cvxopt/amd.so' is referring to 
> /usr/ports/math/sage/work/stage
> Error: 'lib/python3.7/site-packages/cvxopt/misc_solvers.so' is referring to 
> /usr/ports/math/sage/work/stage
> Error: 'lib/python3.7/site-packages/cvxopt/blas.so' is referring to 
> /usr/ports/math/sage/work/stage
> Error: 'lib/python3.7/site-packages/cvxopt/gsl.so' is referring to 
> /usr/ports/math/sage/work/stage
> Error: 'lib/python3.7/site-packages/cvxopt/cholmod.so' is referring to 
> /usr/ports/math/sage/work/stage
> Error: 'lib/python3.7/site-packages/cvxopt/glpk.so' is referring to 
> /usr/ports/math/sage/work/stage
> Error: 'lib/python3.7/site-packages/cvxopt/lapack.so' is referring to 
> /usr/ports/math/sage/work/stage
> Error: 
> 'lib/python3.7/site-packages/sage/numerical/backends/cvxopt_sdp_backend.so' 
> is referring to /usr/ports/math/sage/work/stage
> Error: 
> 'lib/python3.7/site-packages/sage/numerical/backends/cvxopt_backend.so' is 
> referring to /usr/ports/math/sage/work/stage
> 
> When using cvxopt from a system package (see #29665), these errors are
> resolved. Unfortunately, even if the proposed method seems OK from my
> packager´s POV, it seems that this is not the way to go: see #29023.
> 
> Several interesting propositions exist in #29133 (#21566), and things
> like #29653 are also helping, but these are middle or long term goals.
> 
> And so my initial question: how do you package the actual releases? (9.0
> or 9.1)
> 
> Many thanks for reading and for your feedback!
> -- 
> Th. Thomas.
> 
> -- 
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/20200510130219.GA64618%40graf.pompo.net.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/5E507EEF-1448-42F9-A745-FE88DEB0C861%40gmail.com.


[sage-devel] Re: Packaging Sage?

2020-05-10 Thread Timo Kaufmann
As far as I'm aware, everyone's current solution to packaging sage is to 
more or less completely ignore its own build system and do everything 
manually in whatever specification format your package manager uses. You 
will need to make sure it keeps working once the dependencies change. The 
test suite is pretty brittle, but invaluable. It can be done, but you 
should be aware that its pretty labor intensive.

Timo

Am Sonntag, 10. Mai 2020 15:02:24 UTC+2 schrieb Thierry Thomas:
>
> Hello, 
>
> TL;TR: Packagers, how do you deal with Sage to package it for your Linux 
> distribution (or *BSD system)? 
>
> Details: 
>
> Sage has been ported to FreeBSD many years ago (4.8), but now the port 
> is lagging and no more packages are built; I'm trying to fix it. 
>
> Problem: on FreeBSD, packages are built (by a porter or in the 
> compilation farm) as a regular user, and installed in a staging 
> directory (DESTDIR); then the package is installed as root in the final 
> $PREFIX (ldconfig and so on are executed). 
>
> The naming may differ, but many packaging systems have a similar 
> mechanism. 
>
> But Sage cannot be built with this method: the global install target is 
> a no-op, and every sub-package is built and installed during the build 
> target, under $SAGE_LOCAL, and everything is built relatively to this 
> directory. If you try to move the resulting bits to another directory, 
> it becomes unusable. 
>
> $SAGE_DESTDIR is handled, but does not solve this problem. 
>
> A first way to deal with it is to use as many system packages as 
> possible (see #27330): Sage´s libraries built around a system package 
> are safe. 
>
> For example, with the stock sage-9.1.rc3, when setting SAGE_LOCAL to my 
> staging directory, these errors are emitted for cvxopt: 
>
> Error: 'lib/python3.7/site-packages/cvxopt/umfpack.so' is referring to 
> /usr/ports/math/sage/work/stage 
> Error: 'lib/python3.7/site-packages/cvxopt/base.so' is referring to 
> /usr/ports/math/sage/work/stage 
> Error: 'lib/python3.7/site-packages/cvxopt/amd.so' is referring to 
> /usr/ports/math/sage/work/stage 
> Error: 'lib/python3.7/site-packages/cvxopt/misc_solvers.so' is referring 
> to /usr/ports/math/sage/work/stage 
> Error: 'lib/python3.7/site-packages/cvxopt/blas.so' is referring to 
> /usr/ports/math/sage/work/stage 
> Error: 'lib/python3.7/site-packages/cvxopt/gsl.so' is referring to 
> /usr/ports/math/sage/work/stage 
> Error: 'lib/python3.7/site-packages/cvxopt/cholmod.so' is referring to 
> /usr/ports/math/sage/work/stage 
> Error: 'lib/python3.7/site-packages/cvxopt/glpk.so' is referring to 
> /usr/ports/math/sage/work/stage 
> Error: 'lib/python3.7/site-packages/cvxopt/lapack.so' is referring to 
> /usr/ports/math/sage/work/stage 
> Error: 
> 'lib/python3.7/site-packages/sage/numerical/backends/cvxopt_sdp_backend.so' 
> is referring to /usr/ports/math/sage/work/stage 
> Error: 
> 'lib/python3.7/site-packages/sage/numerical/backends/cvxopt_backend.so' is 
> referring to /usr/ports/math/sage/work/stage 
>
> When using cvxopt from a system package (see #29665), these errors are 
> resolved. Unfortunately, even if the proposed method seems OK from my 
> packager´s POV, it seems that this is not the way to go: see #29023. 
>
> Several interesting propositions exist in #29133 (#21566), and things 
> like #29653 are also helping, but these are middle or long term goals. 
>
> And so my initial question: how do you package the actual releases? (9.0 
> or 9.1) 
>
> Many thanks for reading and for your feedback! 
> -- 
> Th. Thomas. 
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/44cee254-250c-4a69-ad34-7247f1535e50%40googlegroups.com.


Re: [sage-devel] Packaging Sage?

2020-05-10 Thread Isuru Fernando
At conda, we don't use system packages at all and use `python setup.py` to
build the sage python package.

https://github.com/conda-forge/sagelib-feedstock/blob/master/recipe/build.sh#L25-L42

Isuru

On Sun, May 10, 2020 at 10:19 AM Thierry Thomas 
wrote:

> Le dim. 10 mai 20 à 16:02:51 +0200, Julien Puydt 
>  écrivait :
>
> > > TL;TR: Packagers, how do you deal with Sage to package it for your
> > > Linux distribution (or *BSD system)?
> >
> >
> > For Debian, we use our packages as much as possible ; the repository
> > can be seen here:
> >
> > https://salsa.debian.org/science-team/sagemath
>
> Thanks Julien and Dima! I did not find the group sage-packaging, and
> I´ll check the Debian pages.
> --
> Th. Thomas.
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-devel/20200510151928.GB64618%40graf.pompo.net
> .
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CA%2B01voPXzWRh5eGYz4KRp%3DDC%3D%2Bmm4-6iwhZ27TjCYBf%3DcLpkEw%40mail.gmail.com.


Re: [sage-devel] Packaging Sage?

2020-05-10 Thread Thierry Thomas
Le dim. 10 mai 20 à 16:02:51 +0200, Julien Puydt 
 écrivait :

> > TL;TR: Packagers, how do you deal with Sage to package it for your
> > Linux distribution (or *BSD system)?
> 
> 
> For Debian, we use our packages as much as possible ; the repository
> can be seen here:
> 
> https://salsa.debian.org/science-team/sagemath

Thanks Julien and Dima! I did not find the group sage-packaging, and
I´ll check the Debian pages.
-- 
Th. Thomas.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/20200510151928.GB64618%40graf.pompo.net.


Re: [sage-devel] Packaging Sage?

2020-05-10 Thread Dima Pasechnik
On Sun, May 10, 2020 at 2:02 PM Thierry Thomas  wrote:
>
> Hello,
>
> TL;TR: Packagers, how do you deal with Sage to package it for your Linux
> distribution (or *BSD system)?

Note that people packaging Sage for Debian, Arch, NixOS are active here:

https://groups.google.com/forum/#!forum/sage-packaging

You can also have a look at say Debian sagemath package:
https://packages.debian.org/sid/sagemath

Sagemath packages which are "straight" C/C++ libraries may be
installed (mostly) using
the usual `make install` targets, I suppose (with appropriate --prefix
set at configure stage
(replace/change calls to sdh_configure by something else)
You might like to replace calls to sdh_install, sdh_make_install etc
in spkg-install.in
to something like `make install`.

HTH
Dima
>
> Details:
>
> Sage has been ported to FreeBSD many years ago (4.8), but now the port
> is lagging and no more packages are built; I'm trying to fix it.
>
> Problem: on FreeBSD, packages are built (by a porter or in the
> compilation farm) as a regular user, and installed in a staging
> directory (DESTDIR); then the package is installed as root in the final
> $PREFIX (ldconfig and so on are executed).
>
> The naming may differ, but many packaging systems have a similar
> mechanism.
>
> But Sage cannot be built with this method: the global install target is
> a no-op, and every sub-package is built and installed during the build
> target, under $SAGE_LOCAL, and everything is built relatively to this
> directory. If you try to move the resulting bits to another directory,
> it becomes unusable.
>
> $SAGE_DESTDIR is handled, but does not solve this problem.
>
> A first way to deal with it is to use as many system packages as
> possible (see #27330): Sage´s libraries built around a system package
> are safe.
>
> For example, with the stock sage-9.1.rc3, when setting SAGE_LOCAL to my
> staging directory, these errors are emitted for cvxopt:
>
> Error: 'lib/python3.7/site-packages/cvxopt/umfpack.so' is referring to 
> /usr/ports/math/sage/work/stage
> Error: 'lib/python3.7/site-packages/cvxopt/base.so' is referring to 
> /usr/ports/math/sage/work/stage
> Error: 'lib/python3.7/site-packages/cvxopt/amd.so' is referring to 
> /usr/ports/math/sage/work/stage
> Error: 'lib/python3.7/site-packages/cvxopt/misc_solvers.so' is referring to 
> /usr/ports/math/sage/work/stage
> Error: 'lib/python3.7/site-packages/cvxopt/blas.so' is referring to 
> /usr/ports/math/sage/work/stage
> Error: 'lib/python3.7/site-packages/cvxopt/gsl.so' is referring to 
> /usr/ports/math/sage/work/stage
> Error: 'lib/python3.7/site-packages/cvxopt/cholmod.so' is referring to 
> /usr/ports/math/sage/work/stage
> Error: 'lib/python3.7/site-packages/cvxopt/glpk.so' is referring to 
> /usr/ports/math/sage/work/stage
> Error: 'lib/python3.7/site-packages/cvxopt/lapack.so' is referring to 
> /usr/ports/math/sage/work/stage
> Error: 
> 'lib/python3.7/site-packages/sage/numerical/backends/cvxopt_sdp_backend.so' 
> is referring to /usr/ports/math/sage/work/stage
> Error: 
> 'lib/python3.7/site-packages/sage/numerical/backends/cvxopt_backend.so' is 
> referring to /usr/ports/math/sage/work/stage
>
> When using cvxopt from a system package (see #29665), these errors are
> resolved. Unfortunately, even if the proposed method seems OK from my
> packager´s POV, it seems that this is not the way to go: see #29023.
>
> Several interesting propositions exist in #29133 (#21566), and things
> like #29653 are also helping, but these are middle or long term goals.
>
> And so my initial question: how do you package the actual releases? (9.0
> or 9.1)
>
> Many thanks for reading and for your feedback!
> --
> Th. Thomas.
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/20200510130219.GA64618%40graf.pompo.net.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq2prG_xCT-xUgkdHHNHA_CkQ%3DhmQ8ONp_46pTwPTi9PHw%40mail.gmail.com.


Re: [sage-devel] Packaging Sage?

2020-05-10 Thread Julien Puydt
Le dimanche 10 mai 2020 à 15:02 +0200, Thierry Thomas a écrit :
> 
> TL;TR: Packagers, how do you deal with Sage to package it for your
> Linux distribution (or *BSD system)?


For Debian, we use our packages as much as possible ; the repository
can be seen here:

https://salsa.debian.org/science-team/sagemath

in particular :
- debian/rules is the script handling the building and it's calling a
pruner.py which makes sagemath use system packages ;
- debian/patches/ has a list of patches to sagemath, to make it
compatible with Debian's packages and file paths.

I hope that helps,

JP

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/e572d55b8bbeb54147748cb5624006743b447fe7.camel%40gmail.com.


[sage-devel] Packaging Sage?

2020-05-10 Thread Thierry Thomas
Hello,

TL;TR: Packagers, how do you deal with Sage to package it for your Linux
distribution (or *BSD system)?

Details:

Sage has been ported to FreeBSD many years ago (4.8), but now the port
is lagging and no more packages are built; I'm trying to fix it.

Problem: on FreeBSD, packages are built (by a porter or in the
compilation farm) as a regular user, and installed in a staging
directory (DESTDIR); then the package is installed as root in the final
$PREFIX (ldconfig and so on are executed).

The naming may differ, but many packaging systems have a similar
mechanism.

But Sage cannot be built with this method: the global install target is
a no-op, and every sub-package is built and installed during the build
target, under $SAGE_LOCAL, and everything is built relatively to this
directory. If you try to move the resulting bits to another directory,
it becomes unusable.

$SAGE_DESTDIR is handled, but does not solve this problem.

A first way to deal with it is to use as many system packages as
possible (see #27330): Sage´s libraries built around a system package
are safe.

For example, with the stock sage-9.1.rc3, when setting SAGE_LOCAL to my
staging directory, these errors are emitted for cvxopt:

Error: 'lib/python3.7/site-packages/cvxopt/umfpack.so' is referring to 
/usr/ports/math/sage/work/stage
Error: 'lib/python3.7/site-packages/cvxopt/base.so' is referring to 
/usr/ports/math/sage/work/stage
Error: 'lib/python3.7/site-packages/cvxopt/amd.so' is referring to 
/usr/ports/math/sage/work/stage
Error: 'lib/python3.7/site-packages/cvxopt/misc_solvers.so' is referring to 
/usr/ports/math/sage/work/stage
Error: 'lib/python3.7/site-packages/cvxopt/blas.so' is referring to 
/usr/ports/math/sage/work/stage
Error: 'lib/python3.7/site-packages/cvxopt/gsl.so' is referring to 
/usr/ports/math/sage/work/stage
Error: 'lib/python3.7/site-packages/cvxopt/cholmod.so' is referring to 
/usr/ports/math/sage/work/stage
Error: 'lib/python3.7/site-packages/cvxopt/glpk.so' is referring to 
/usr/ports/math/sage/work/stage
Error: 'lib/python3.7/site-packages/cvxopt/lapack.so' is referring to 
/usr/ports/math/sage/work/stage
Error: 
'lib/python3.7/site-packages/sage/numerical/backends/cvxopt_sdp_backend.so' is 
referring to /usr/ports/math/sage/work/stage
Error: 'lib/python3.7/site-packages/sage/numerical/backends/cvxopt_backend.so' 
is referring to /usr/ports/math/sage/work/stage

When using cvxopt from a system package (see #29665), these errors are
resolved. Unfortunately, even if the proposed method seems OK from my
packager´s POV, it seems that this is not the way to go: see #29023.

Several interesting propositions exist in #29133 (#21566), and things
like #29653 are also helping, but these are middle or long term goals.

And so my initial question: how do you package the actual releases? (9.0
or 9.1)

Many thanks for reading and for your feedback!
-- 
Th. Thomas.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/20200510130219.GA64618%40graf.pompo.net.