Re: [sage-devel] Packaging Sage?
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?
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?
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?
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?
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?
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?
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.