Re: [sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[François Bissey]

On 16/04/24 04:41, kcrisman wrote:

SageMath has several other long-term contributors who also package
software. We're all roughly on the same page about what it would take
to fix the sage installation for end users.


And some of these people (perhaps kiwifb?) have not been as directly 
involved in some of the recent disputes.   Maybe there is a path forward 
(I also presume the CoCC is thinking about this).


I would say I have involved myself too much already. I am regularly 
asked to review some of those tickets that are disputed or become disputed.


It floods my inbox and makes my heart sink.

François

--
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/d7dd2f74-8c1a-4e9a-be42-5b4816065e30%40gmail.com.

Re: [sage-devel] jupyterlab on sage 10.2

[François Bissey]

If you do that from a terminal, there should be a number of messages 
spat back at you before the browser start jupyterlab.

Can you post them?

François

On 28/02/24 09:41, Jan Groenewald wrote:

Hi

sage 10.2 on Debian 12, and
sage -i jupyterlab

sage --notebook=jupyterlab

launches, and the logo displays and animates, and then stops. I can't 
get further. Any ideas?


This was working in sage 10.1.

Regards,
Jan

--
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/CAAg%3Dp_1eYsYAHsZF_6fYNnGOQqLrzoCSROyakXz%3DiQ3KMWd8gw%40mail.gmail.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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/873a42dd-8f9a-4d51-80e5-284f48af8dc8%40gmail.com.

Re: [sage-devel] trying to build sage10.1

[François Bissey]

From the log sent to me in a private email:
[sagelib-10.1] gcc -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 
-DNDEBUG -O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall 
-Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 
-Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection 
-O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall 
-Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 
-Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection 
-O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall 
-Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 
-Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -g 
-O2 -fPIC -Isage/cpython 
-I/home/ayan/programs/sage-10.1/local/var/lib/sage/venv-python3.11/lib64/python3.11/site-packages/cysignals 
-I/home/ayan/programs/sage-10.1/src 
-I/home/ayan/programs/sage-10.1/local/var/lib/sage/venv-python3.11/lib64/python3.11/site-packages/numpy/core/include 
-I/usr/include/python3.11 
-I/home/ayan/programs/sage-10.1/local/var/lib/sage/venv-python3.11/include 
-I/usr/include/python3.11 -c sage/stats/time_series.c -o 
build/temp.linux-x86_64-cpython-311/sage/stats/time_series.o
[sagelib-10.1] /usr/bin/ld: ///usr/local/lib/libntl.a(ZZ.o): 
relocation R_X86_64_32S against `.rodata' can not be used when making a 
shared object; recompile with -fPIC
[sagelib-10.1] /usr/bin/ld: failed to set dynamic section sizes: bad 
value

[sagelib-10.1] collect2: error: ld returned 1 exit status

We are looking at a "local" installation of NTL [not sage provided] 
which does not have the right properties.

I would recommend uninstalling it and build the version shipped with sage.

François


On 27/10/23 20:15, Ayan Mahalanobis wrote:

Hi All,

I am trying to build sage 10.1 from source with no luck. I am using 
fedora 38. It uses gcc 13. The error occurs when it tries to build 
sagelib is below.


This is the command it ran just before exit code 1 from g++. It is nasty 
looking and I am sorry for that. Any help much appreciated.

==
gcc -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -O2 
-fexceptions -g -grecord-gcc-switches -pipe -Wall 
-Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 
-Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection 
-O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall 
-Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 
-Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection 
-O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall 
-Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 
-Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -g 
-O2 -fPIC -I/usr/include/singular -Isage/symbolic -Isage/cpython 
-I/home/ayan/programs/sage-10.1/local/var/lib/sage/venv-python3.11/lib64/python3.11/site-packages/cypari2 -I/home/ayan/programs/sage-10.1/local/var/lib/sage/venv-python3.11/lib64/python3.11/site-packages/cysignals -I/home/ayan/programs/sage-10.1/src -I/home/ayan/programs/sage-10.1/local/var/lib/sage/venv-python3.11/lib64/python3.11/site-packages/numpy/core/include -I/usr/include/python3.11 -I/home/ayan/programs/sage-10.1/local/var/lib/sage/venv-python3.11/include -I/usr/include/python3.11 -c sage/symbolic/ginac/wildcard.cpp -o build/temp.linux-x86_64-cpython-311/sage/symbolic/ginac/wildcard.o -std=c++11 -I/usr/include/singular -DSING_NDEBUG -DOM_NDEBUG
[sagelib-10.1]     g++ -std=gnu++11 -shared -Wl,-z,relro -Wl,--as-needed 
-Wl,-z,now -Wl,--build-id=sha1 -Wl,-z,relro -Wl,--as-needed -Wl,-z,now 
-Wl,--build-id=sha1 
-Wl,-rpath-link,/home/ayan/programs/sage-10.1/local/lib 
-L/home/ayan/programs/sage-10.1/local/lib 
-Wl,-rpath,/home/ayan/programs/sage-10.1/local/lib 
-Wl,-rpath-link,/home/ayan/programs/sage-10.1/local/lib 
-L/home/ayan/programs/sage-10.1/local/lib 
-Wl,-rpath,/home/ayan/programs/sage-10.1/local/lib -g -O2 
build/temp.linux-x86_64-cpython-311/sage/symbolic/expression.o 
build/temp.linux-x86_64-cpython-311/sage/symbolic/ginac/add.o 
build/temp.linux-x86_64-cpython-311/sage/symbolic/ginac/archive.o 
build/temp.linux-x86_64-cpython-311/sage/symbolic/ginac/assume.o 
build/temp.linux-x86_64-cpython-311/sage/symbolic/ginac/basic.o 
build/temp.linux-x86_64-cpython-311/sage/symbolic/ginac/cmatcher.o 
build/temp.linux-x86_64-cpython-311/sage/symbolic/ginac/constant.o 
build/temp.linux-x86_64-cpython-311/sage/symbolic/ginac/context.o 

Re: [sage-devel] trying to build sage10.1

[François Bissey]

Hi,

We need the build log. The last output is not always where the error 
occurred. On most modern system there are several compilations done at 
the same time. The last one printed is just the last one to finish.


François

On 27/10/23 20:15, Ayan Mahalanobis wrote:

Hi All,

I am trying to build sage 10.1 from source with no luck. I am using 
fedora 38. It uses gcc 13. The error occurs when it tries to build 
sagelib is below.


This is the command it ran just before exit code 1 from g++. It is nasty 
looking and I am sorry for that. Any help much appreciated.

==
gcc -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -O2 
-fexceptions -g -grecord-gcc-switches -pipe -Wall 
-Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 
-Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection 
-O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall 
-Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 
-Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection 
-O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall 
-Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 
-Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -g 
-O2 -fPIC -I/usr/include/singular -Isage/symbolic -Isage/cpython 
-I/home/ayan/programs/sage-10.1/local/var/lib/sage/venv-python3.11/lib64/python3.11/site-packages/cypari2 -I/home/ayan/programs/sage-10.1/local/var/lib/sage/venv-python3.11/lib64/python3.11/site-packages/cysignals -I/home/ayan/programs/sage-10.1/src -I/home/ayan/programs/sage-10.1/local/var/lib/sage/venv-python3.11/lib64/python3.11/site-packages/numpy/core/include -I/usr/include/python3.11 -I/home/ayan/programs/sage-10.1/local/var/lib/sage/venv-python3.11/include -I/usr/include/python3.11 -c sage/symbolic/ginac/wildcard.cpp -o build/temp.linux-x86_64-cpython-311/sage/symbolic/ginac/wildcard.o -std=c++11 -I/usr/include/singular -DSING_NDEBUG -DOM_NDEBUG
[sagelib-10.1]     g++ -std=gnu++11 -shared -Wl,-z,relro -Wl,--as-needed 
-Wl,-z,now -Wl,--build-id=sha1 -Wl,-z,relro -Wl,--as-needed -Wl,-z,now 
-Wl,--build-id=sha1 
-Wl,-rpath-link,/home/ayan/programs/sage-10.1/local/lib 
-L/home/ayan/programs/sage-10.1/local/lib 
-Wl,-rpath,/home/ayan/programs/sage-10.1/local/lib 
-Wl,-rpath-link,/home/ayan/programs/sage-10.1/local/lib 
-L/home/ayan/programs/sage-10.1/local/lib 
-Wl,-rpath,/home/ayan/programs/sage-10.1/local/lib -g -O2 
build/temp.linux-x86_64-cpython-311/sage/symbolic/expression.o 
build/temp.linux-x86_64-cpython-311/sage/symbolic/ginac/add.o 
build/temp.linux-x86_64-cpython-311/sage/symbolic/ginac/archive.o 
build/temp.linux-x86_64-cpython-311/sage/symbolic/ginac/assume.o 
build/temp.linux-x86_64-cpython-311/sage/symbolic/ginac/basic.o 
build/temp.linux-x86_64-cpython-311/sage/symbolic/ginac/cmatcher.o 
build/temp.linux-x86_64-cpython-311/sage/symbolic/ginac/constant.o 
build/temp.linux-x86_64-cpython-311/sage/symbolic/ginac/context.o 
build/temp.linux-x86_64-cpython-311/sage/symbolic/ginac/ex.o 
build/temp.linux-x86_64-cpython-311/sage/symbolic/ginac/expair.o 
build/temp.linux-x86_64-cpython-311/sage/symbolic/ginac/expairseq.o 
build/temp.linux-x86_64-cpython-311/sage/symbolic/ginac/exprseq.o 
build/temp.linux-x86_64-cpython-311/sage/symbolic/ginac/fderivative.o 
build/temp.linux-x86_64-cpython-311/sage/symbolic/ginac/function.o 
build/temp.linux-x86_64-cpython-311/sage/symbolic/ginac/function_info.o 
build/temp.linux-x86_64-cpython-311/sage/symbolic/ginac/infinity.o 
build/temp.linux-x86_64-cpython-311/sage/symbolic/ginac/infoflagbase.o 
build/temp.linux-x86_64-cpython-311/sage/symbolic/ginac/inifcns.o 
build/temp.linux-x86_64-cpython-311/sage/symbolic/ginac/inifcns_comb.o 
build/temp.linux-x86_64-cpython-311/sage/symbolic/ginac/inifcns_gamma.o 
build/temp.linux-x86_64-cpython-311/sage/symbolic/ginac/inifcns_hyperb.o 
build/temp.linux-x86_64-cpython-311/sage/symbolic/ginac/inifcns_hyperg.o 
build/temp.linux-x86_64-cpython-311/sage/symbolic/ginac/inifcns_nstdsums.o build/temp.linux-x86_64-cpython-311/sage/symbolic/ginac/inifcns_orthopoly.o build/temp.linux-x86_64-cpython-311/sage/symbolic/ginac/inifcns_trans.o build/temp.linux-x86_64-cpython-311/sage/symbolic/ginac/inifcns_trig.o build/temp.linux-x86_64-cpython-311/sage/symbolic/ginac/inifcns_zeta.o build/temp.linux-x86_64-cpython-311/sage/symbolic/ginac/lst.o build/temp.linux-x86_64-cpython-311/sage/symbolic/ginac/matrix.o build/temp.linux-x86_64-cpython-311/sage/symbolic/ginac/mpoly-giac.o build/temp.linux-x86_64-cpython-311/sage/symbolic/ginac/mpoly-ginac.o build/temp.linux-x86_64-cpython-311/sage/symbolic/ginac/mpoly-singular.o build/temp.linux-x86_64-cpython-311/sage/symbolic/ginac/mpoly.o 

Re: [sage-devel] Demote brial (= polybori) from standard to experimental

[François Bissey]

Please remove that pain from my a**.
Seriously, I am not sure why it leads to so many issues. I have been 
combing the code on a regular basis for compiler warnings and stuff and 
fixing them.
Debian has issue with the dead brial python interface package, which is 
definitely unmaintained because we moved the essential bits inside sage.

Why they persisted with it, I do not know.
If people have issues, I welcome them opening them on the tracker so I 
can look at them.

Nevertheless moving to newer, better maintained stuff would make my day.

François Bissey

On 2/10/23 08:29, Matthias Koeppe wrote:

I propose to demote this package to experimental.
- It has been declared dead at least once -  
https://martinralbrecht.wordpress.com/2015/06/13/polybori-is-dead-it-needs-your-help/
- It has no upstream maintainer (except for ermergency fixes by Francois 
Bissey) - 
https://github.com/BRiAl/BRiAl/graphs/contributors, https://sourceforge.net/projects/polybori/
- It has been dropped from Debian testing, where it seems to block 
SageMath upgrades (Sage is stuck at 9.5 in Debian/Ubuntu)
- The conda and homebrew packages of brial lead to segfaults 
(https://github.com/sagemath/sage/issues/35595, https://github.com/sagemath/sage/issues/34780)
- It is disconnected from the advances in SMT (satisfiability modulo 
theories) over the past decade (representative 
paper: https://arxiv.org/abs/2305.00028v2)




--
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 
<mailto:sage-devel+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/76bc224b-8ed0-4274-9811-1d118737a8edn%40googlegroups.com <https://groups.google.com/d/msgid/sage-devel/76bc224b-8ed0-4274-9811-1d118737a8edn%40googlegroups.com?utm_medium=email_source=footer>.


--
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/453f1e78-46e1-c1eb-1fed-6a777bf144d0%40gmail.com.

Re: [sage-devel] Question about real names in the new github workflow

[François Bissey]

Never mind names, in a perfect world I want the orcid of all the 
contributors who have one. In that same perfect world all sage 
contributors have one.
This is scientific output and authorship and uniquely identifying 
authors is what orcid is for.

https://orcid.org/

On 8/02/23 22:16, Dima Pasechnik wrote:



On Wed, 8 Feb 2023, 08:28 Tobias Diez, > wrote:


Wouldn't it be easier to automate (and more respectful to the
privacy concerns of contributors) to simply link to the github
handle/profile?


GitHub profiles don't always have real names.


On Wednesday, 8 February 2023 at 04:51:30 UTC+8 Matthias Koeppe wrote:

We have collected these mappings in
https://github.com/sagemath/website/blob/master/conf/contributors.xml 
, which 
would be easy to read from in a GH Actions workflow.



On Tuesday, February 7, 2023 at 8:58:51 AM UTC-8 Dima Pasechnik
wrote:



On Tue, 7 Feb 2023, 11:33 'Martin R' via sage-devel,
 wrote:

Has there been already a decision how we incorporate the
real name "Author" and "Reviewer" fields?

I think that this is rather important, because not
making a decision will probably also be a decision -
there are already several new pull requests.

Personally, I am very much for continuing the tradition
of real names, but it is not clear to me whether there
is a mapping between user name and real name on github
anyway, which would make this information redundant.  Is
the "Name" in a github account optional?


yes, names are optional on GitHub, so we will need some kind
of mapping to keep.

We can also get names of authors and reviewers in the PR
description enforced by a bot.
We can also require this info to be put in a special
textfile to be collected at merging time and put into a
changelog file.
(amending changelog directly is prone to conflicts).


Martin

-- 
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/c2c8654a-0511-43a7-a7e5-66c6e687178an%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+unsubscr...@googlegroups.com
.
To view this discussion on the web visit

https://groups.google.com/d/msgid/sage-devel/e90c1072-9ff3-4392-9c4a-a133c22de288n%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+unsubscr...@googlegroups.com 
.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq0CDgMMUwFTZv%3D8xp3u65R-S62Sq4O_oM9AcNEow71w8Q%40mail.gmail.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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/7ad82572-bd6c-4557-8fa1-2a54cd2eeb9e%40gmail.com.

Re: [sage-devel] Re: Announcement: we are approaching to the GitHub planet

[François Bissey]

It 404 for me. I am guessing it is not public yet.

On 3/02/23 16:05, Matthias Koeppe wrote:
Only 10% of the final approach (import) are done, but the impatient can 
already take a look at https://github.com/sagemath/sage/issues: The 
attribution of imported issues to GitHub users and the creation of 
mannequins seem to work as we hoped!


On Thursday, February 2, 2023 at 4:56:37 PM UTC-8 Kwankyu Lee wrote:

It should be visible, soon!

--
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/ad5143d8-df3c-40c6-a90b-2a0dd66ecbbfn%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/b2392a4d-ea8a-abac-cda0-c068370b4d45%40gmail.com.

Re: [sage-devel] online talk about the github workflow

[François Bissey]

On 3/02/23 10:30, David Joyner wrote:

Hi Vincent:
Will this be recorded and posted on youtube,
or something like that?
- David



I am seconding that request. That time is 5:30am in my time zone.

François (NZST=UTC+13 at this time of the year)

--
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/31ef3b4b-4183-4de8-dc0e-c02d9939dce8%40gmail.com.

Re: [sage-devel] Re: MIgration to GitHub: Heads-up on org invitations

[François Bissey]

People are certainly receiving and applying. I see the number of people 
in the organization growing steadily since this morning.


François

On 2/02/23 15:23, Kwankyu Lee wrote:

I received the invitation an hour ago. It worked great!

--
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/43a37b9d-1d90-4db7-a94d-83931c7a0bd2n%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/5fdd486d-e87f-381a-0352-13a267324fd2%40gmail.com.

Re: [sage-devel] Re: The build of giac-1.9.0.15p0 in sage-9.7 failed on fedora-37 (x86_64)

[François Bissey]

I believe it is because you have pari-2.15 and giac is not compatible 
out of the box with that version of pari. There is a patch on trac for 
the next giac upgrade.


François

On 20/11/22 23:10, enriqu...@gmail.com wrote:
I had the same issue, running ./configure --with-system-pari=no before 
make solved the issue


El sábado, 19 de noviembre de 2022 a las 13:33:07 UTC+1, 
furutaka@gmail.com escribió:


(It compiled w/o any trouble on the previous version of fedora (36)...)

-- 
Kazuyoshi Furutaka


--
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/c7901d87-3aac-4013-91df-84ed16fd52ddn%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/9eb55ef2-465f-f768-f84b-957440984390%40gmail.com.

Re: [sage-devel] Re: Invitation: Weekly 30-minute Sage developer calls on Jitsi

[François Bissey]

On 8/11/22 07:36, Matthias Koeppe wrote:

Updated times for Europe / Africa / Americas after DST changes:

Monday noon, 12:15pm San Francisco
Monday afternoon, 3:15pm New York
Monday afternoon, 17:15 Rio de Janeiro & Santiago de Chile
Monday evening, 21:15 Paris
Monday evening, 22:15 Johannesburg


Tuesday morning, 9:15am Auckland :)

I may be able to make that one, but it clashes with an early meeting - 
which I will not be sorry to miss :)


François

--
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/9985a19d-8c75-5c44-0114-53eacafeca82%40gmail.com.

Re: [sage-devel] Re: Invitation: Weekly 30-minute Sage developer calls on Jitsi

[François Bissey]

Note that New Zealand has switched to daylight saving (or from I never 
remember, French call them winter time and summer time, much easier) in 
the last few weeks. So, the calling time was 3:15pm for me.
I would be able to make 2:15pm, but not 3:15pm as I get a kid from 
school at that time. 4:15 is out this week too.


On 14/10/22 15:00, Matthias Koeppe wrote:

Thursday evening, 7:15pm Oakland (California)
Thursday evening, 10:15pm New York
Friday afternoon, 2:15pm Auckland (New Zealand)
Friday morning, 11:15 Tokyo



François

--
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/1be3b059-ff00-bbf7-d849-e11fe639d429%40gmail.com.

Re: [sage-devel] Invitation: Weekly Sage developer calls on Zoom, starting this Thursday!

[François Bissey]

I am in the middle of picking a kid from school at that time so I won't 
be there for that one tomorrow. Filled my bit in the pool.


On 15/09/22 06:36, Matthias Koeppe wrote:

Friday afternoon, 3:15pm Auckland (New Zealand)


François

--
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/43fa7b53-0ebf-fb45-20da-54fd20e2edfa%40gmail.com.

Re: [sage-devel] Please add your GitHub account name to the SageMath contributor info

[François Bissey]

It appears my info was all correct already. I removed my info from the 
trac landing page.


I notice there is some confusion in what the label "work" means. Some 
people put their position rather than their institution. I don't think

that's a big deal but if that's you :) you can fix that too.

From the top of contributors.xml

contributor
 + name
 - location = something which returns the correct location when entered 
in maps.google.com

 - work = university, institute, ...

Sometimes "location" and "work" are the same and that's OK.

On 13/09/22 00:12, Matthias Koeppe wrote:

Dear Sage developers (current and past):

The SageMath developer map 
(https://www.sagemath.org/development-map.html 
) needs your updated 
information.


In particular, motivated by the proposed migration from Trac to GitHub 
Issues/PRs (https://trac.sagemath.org/ticket/30363), we will need your 
GitHub account name by September 26.

(If you don't have a GitHub account yet, now is a great time to open one.)

The source code of the Sage website is maintained in the GitHub 
repository https://github.com/sagemath/website; to add yourself or to 
update your information shown in the development map, edit the file 
https://github.com/sagemath/website/blob/master/conf/contributors.xml 
 and 
send a pull request (PR).

- For your GitHub user name, use the "github" attribute.
- For your (legacy) Trac user name, use the "trac" attribute. If you 
already use a GitHub login for Trac, i.e., your Trac user name starts 
with "gh-", there is no need to add the "trac" attribute.
- If you have a Gitlab.com account, you can also add that if you want, 
using the "gitlab" attribute.


You can do all of this editing directly on GitHub by clicking the "Edit" 
button; or, if you prefer, you can fork the repository, clone it to your 
computer, edit it there, commit the change, push it to your fork, and 
send a PR.


We would also like to consolidate the Sage developer map information 
with the information currently at 
https://trac.sagemath.org/#AccountNamesMappedtoRealNames; if your name 
appears on this Trac page, please help us by doing the following:
- review the information there, move it to the contributors.xml file, 
and then delete it from the Trac page.




--
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/acf337af-35a6-4efb-a16c-bcb32863a78dn%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/b7d01324-0fcd-2789-e7c7-07e705ef1060%40gmail.com.

[sage-devel] Re: Trac #34152 needs you (to vote)!

[François Bissey]

The vote is now closed.
Hybrid:  8 top votes
pseudo-package: 2 top votes
copy: 0 top votes

Thanks to all voters.

François
On Wednesday, August 24, 2022 at 11:38:40 AM UTC+12 François Bissey wrote:

> Hi all,
>
> https://trac.sagemath.org/ticket/34152 needs help to decide what solution 
> we implement going forward.
>
> The ticket is concerned with updating the bootstrap process by removing 
> the current need for gettext and replacing it with gnulib (
> https://www.gnu.org/software/gnulib). gnulib is not a regular software 
> library but a collection of bits and pieces to help portability across 
> platforms.
>
> The issue at hand is how do we include and use gnulib in sagemath.
> Matthias Koeppe and Dima Pasechnik have been arguing for several weeks and 
> across most of the ~250 comments of the ticket about the way to proceed. At 
> some point it became clear that they would not agree and would need 
> arbitration. This is what this post is about, I am inviting the sagemath 
> community to weigh in and decide the issue.
>
> The ticket summary has been updated with summaries of the problem and of 
> both options along with links to branches implementing them. I would not 
> recommend diving in the comment section.
>
> There are 3 (three) options to choose from, one from Matthias, one from 
> Dima and a hybrid approach they tried to create.
>
> -- copy files --
>
>- Follows approach 3 of the Gnulib manual section 'Integration with 
>Version Control Systems' 
><https://www.gnu.org/software/gnulib/manual/html_node/VCS-Issues.html>.
>- 5 files, in config/ and m4/, total 112 KB, have been imported by 
>using `gnulib-tool import iconv` 
><https://www.gnu.org/software/gnulib/manual/html_node/Initial-import.html> 
> and 
>committed to the branch.
>- Matches our practice with imported files `m4/ax_*.m4` 
><https://github.com/sagemath/sage/tree/develop/m4> from 
>autoconf-archive 
><https://www.gnu.org/software/autoconf-archive/The-Macros.html>. 
>Different from our practice with SPKGs because the files are needed to 
>generate the configure script.
>- Introduces no new dependency.
>- Burden on a developer who authors an update ticket for these files: 
>Obtain gnulib by cloning the repo, then re-run gnulib-tool import, 
>remove unneeded files (that's where #29549 
><https://trac.sagemath.org/ticket/29549> went wrong), commit the 
>changes. (Updates are expected to be necessary only very rarely.)
>- Burden on users and other developers: None.
>- dimpase's criticism of this approach: "gnulib's code is not Sage's 
>code, it has no place in Sage git tree; this way, updating the imported 
>gnulib files is tricky and error-prone by design".
>
> -- sage pseudo package --
>
>- Follows approach 2(C) of the Gnulib manual section 'Integration with 
>Version Control Systems' 
><https://www.gnu.org/software/gnulib/manual/html_node/VCS-Issues.html>, 
>but instead of using Gnulib's Programs for developing in Git checkouts 
>
> <https://www.gnu.org/software/gnulib/manual/html_node/Developer-tools.html>, 
>implements its own script (making checkout much faster, as full gnulib 
> checkout 
>is 250 MB).
>- Introduces a new (although one can't really do Sage development 
>without git installed) dependency on git and on availability of 
>internet connection at the first run of ./bootstrap in a tree, to pull 
>83 MB (fair to say that internet is needed for Sage development a lot, 
>anyway).
>- Burden on a developer who authors an update ticket for these files: 
>Edit the bootstrap file to change the commit hash, verify that the 
>list of files removed by make bootstrap-clean is still correct, commit 
>this change
>- Burden on other users: a pseudo-package needs to be installed once 
>(and updated, automatically)
>- mkoeppe's criticism of this approach: "Having bootstrap operate a 
>multi-megabyte git clone (on the 1st install and when there's a change of 
>the gnulib commit hash) in the upstream/ directory increases 
>complexity for no benefit."
>
> -- hybrid --
>
>- Resolves the criticism on the "copy files" approach: "updating the 
>imported gnulib files" is now assisted by the spkg-src script (adapted 
>from dimpase's branch)
>- Resolves the criticism on the "Sage pseudo-package" approach: 
>"operate a multi-megabyte git clone (on the 1st install and when there's a 
>change of the gnulib commit hash)" is only done by authors of tickets that 
>update gnulib, not by ge

Re: [sage-devel] Re: Trac #34152 needs you (to vote)!

[François Bissey]

In the interest of clarity and ease of counting for me, can we keep the 
thread onto votes and possibly voting issues.


Arguments should go back to the ticket or a separate thread please.

François

On 24/08/22 12:43, Matthias Koeppe wrote:

On Tuesday, August 23, 2022 at 5:34:01 PM UTC-7 Travis Scrimshaw wrote:

I also fully agree with Dima that gnulib has no business being in
Sage's git tree


This is a mischaracterization. None of the approaches puts "gnulib in 
the Sage git tree". I recommend to read the discussion on the ticket.


--
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/dc9d3f46-389e-48f5-9110-1e782dd1bfb9n%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/08667017-53fa-a087-307e-d3672e9d842f%40gmail.com.

[sage-devel] Trac #34152 needs you (to vote)!

[François Bissey]

Hi all,

https://trac.sagemath.org/ticket/34152 needs help to decide what solution
we implement going forward.

The ticket is concerned with updating the bootstrap process by removing the
current need for gettext and replacing it with gnulib (
https://www.gnu.org/software/gnulib). gnulib is not a regular software
library but a collection of bits and pieces to help portability across
platforms.

The issue at hand is how do we include and use gnulib in sagemath.
Matthias Koeppe and Dima Pasechnik have been arguing for several weeks and
across most of the ~250 comments of the ticket about the way to proceed. At
some point it became clear that they would not agree and would need
arbitration. This is what this post is about, I am inviting the sagemath
community to weigh in and decide the issue.

The ticket summary has been updated with summaries of the problem and of
both options along with links to branches implementing them. I would not
recommend diving in the comment section.

There are 3 (three) options to choose from, one from Matthias, one from
Dima and a hybrid approach they tried to create.

-- copy files --

   - Follows approach 3 of the Gnulib manual section 'Integration with
   Version Control Systems'
   .
   - 5 files, in config/ and m4/, total 112 KB, have been imported by
using `gnulib-tool
   import iconv`
   
and
   committed to the branch.
   - Matches our practice with imported files `m4/ax_*.m4`
    from autoconf-archive
   .
   Different from our practice with SPKGs because the files are needed to
   generate the configure script.
   - Introduces no new dependency.
   - Burden on a developer who authors an update ticket for these files:
   Obtain gnulib by cloning the repo, then re-run gnulib-tool import,
   remove unneeded files (that's where #29549
    went wrong), commit the
   changes. (Updates are expected to be necessary only very rarely.)
   - Burden on users and other developers: None.
   - dimpase's criticism of this approach: "gnulib's code is not Sage's
   code, it has no place in Sage git tree; this way, updating the imported
   gnulib files is tricky and error-prone by design".

-- sage pseudo package --

   - Follows approach 2(C) of the Gnulib manual section 'Integration with
   Version Control Systems'
   ,
   but instead of using Gnulib's Programs for developing in Git checkouts
   ,
   implements its own script (making checkout much faster, as full
gnulib checkout
   is 250 MB).
   - Introduces a new (although one can't really do Sage development
   without git installed) dependency on git and on availability of internet
   connection at the first run of ./bootstrap in a tree, to pull 83 MB
   (fair to say that internet is needed for Sage development a lot, anyway).
   - Burden on a developer who authors an update ticket for these files:
   Edit the bootstrap file to change the commit hash, verify that the list
   of files removed by make bootstrap-clean is still correct, commit this
   change
   - Burden on other users: a pseudo-package needs to be installed once
   (and updated, automatically)
   - mkoeppe's criticism of this approach: "Having bootstrap operate a
   multi-megabyte git clone (on the 1st install and when there's a change of
   the gnulib commit hash) in the upstream/ directory increases complexity
   for no benefit."

-- hybrid --

   - Resolves the criticism on the "copy files" approach: "updating the
   imported gnulib files" is now assisted by the spkg-src script (adapted
   from dimpase's branch)
   - Resolves the criticism on the "Sage pseudo-package" approach: "operate
   a multi-megabyte git clone (on the 1st install and when there's a change of
   the gnulib commit hash)" is only done by authors of tickets that update
   gnulib, not by general users of bootstrap.

Vote is open now and will close - tentatively - on the 29th of August at
12pm New Zealand time [my time zone] when I will do the tally. If no option
gets a majority, the voting period may be extended by a few days.
Please vote!
[ ] copy files
[ ] sage pseudo package
[ ] hybrid

-- 
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/CAP1Dv6a4xp5a1y-idOms4yHKCG1sv%2BzO771rQ0MUxrmAfL%2BLRQ%40mail.gmail.com.

Re: [sage-devel] configure problem

[François Bissey]

https://trac.sagemath.org/ticket/33316 that’s what happened. Support for gcc 
lower than 6.3 removed. I don’t know if you can get a newer gcc from that 
ubuntu.

> On 22/06/2022, at 22:56, John Cremona  wrote:
> 
> On a machine (Ubuntu 16.04.7 LTS) on which I have done a lot of Sage
> development before,  and  successfully built sage from source, from
> scratch,  just a month ago (May 17 when 9.6 was released) with no
> problems.
> 
> Now, I made a new clone of the source using
> 
> git clone https://github.com/sagemath/sage.git
> cd sage
> 
> then ran
> 
> ./bootstrap
> 
> and then
> 
> ./configure
> 
> but configure gave some error messages.  In the long list, I see
> 
> gcc-11.3.0:  no suitable system
> package; this is an error
> 
> and at the end:
> 
> configure: error:
> 
>Given --with-system-gcc=force, but no system package could be used.
>That's an error.  Please install the indicated package to continue.
>(To override this error, use ./configure --without-system-gcc)
> 
> Now this system certainly has a working gcc, it is
> gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.12)
> 
> Also,  So, what has changed since then?
> 
> John
> 
> -- 
> 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/CAD0p0K79NBC7Hv49MNY9keGR-siU0xfOnmJ2Ab%2B54FUXgpxwhg%40mail.gmail.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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/DA2BF98B-B926-4F70-A597-CCEC9B44749C%40gmail.com.

Re: [sage-devel] Virtual Sage Days June 1–3: Preliminary program, Registration

[François Bissey]

I’d seriously watch your talk (The way to a fully modularized Sage library 
10.0) live and chat but I’ll be driving kids to school at that time :)
I’ll have to enjoy the replay later in the day.

François

> On 26/05/2022, at 18:57, Matthias Koeppe  wrote:
> 
> Preliminary program:
> https://researchseminars.org/seminar/SageDays112358
> 
> Please register:
> https://sagemath.zulipchat.com/#narrow/stream/321245-sd112.2E358/topic/Registration
> 
> It is still possible to contribute talks, tutorials, coding sprints, and 
> other activities
> 
> -- 
> 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/b94af80d-9ece-42f7-9f26-9b847f9af9a7n%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/8B732490-62F1-4131-BA9E-8BEA289956B1%40gmail.com.

Re: [sage-devel] file reported missing during install

[François Bissey]

And trivial https://trac.sagemath.org/ticket/33859 is ready for review.

> On 17/05/2022, at 12:24, François Bissey  wrote:
> 
> Right, I’ll open a ticket for that.
> 
>> On 17/05/2022, at 12:11, Matthias Koeppe  wrote:
>> 
>> It looks like this directory was removed in #27155, so this line can be 
>> removed from MANIFEST.in
>> 
>> 
>> On Monday, May 16, 2022 at 4:31:50 PM UTC-7 François Bissey wrote:
>> Hi, 
>> 
>> I have noticed it before but I have only started to wonder about it while 
>> preparing the 9.6 release for Gentoo. 
>> During the install phase while the wheel is being prepared I have the 
>> following messages 
>> 
>> listing git files failed - pretending there aren't any 
>> warning: no files found matching '*.hh' anywhere in distribution 
>> warning: no files found matching '*.inc' anywhere in distribution 
>> no previously-included directories found matching '.tox' 
>> warning: no directories found matching 'sage/libs/gap/test' 
>> no previously-included directories found matching 'sage_setup' 
>> * Installing the wheel to 
>> /var/tmp/portage/sci-mathematics/sage-9.6/work/sagemath-standard-9.6-python3_10/install
>>  
>> 
>> Nothing really surprising except for that “sage/libs/gap/test” directory 
>> seemingly coming out of nowhere. 
>> 
>> Inspecting the source in git, it seems to come from src/MANIFEST.in 
>> src/MANIFEST.in:graft sage/libs/gap/test 
>> which ultimately is shipped inside the sage math-standard sdist as its 
>> regular MANIFEST.in file. 
>> Is this something that should be removed or that is actually incorrect? 
>> There is no such folder but there are two files called 
>> sage/libs/gap/test.py 
>> sage/libs/gap/test_long.py 
>> in the sources and they are installed as regular python files as part of 
>> sagemath-standard. 
>> 
>> François
>> 
>> -- 
>> 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/d5a4df47-5098-489a-8910-2ddfc656144en%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/D35A4FBC-EE74-4707-9C06-6973F5A68AE3%40gmail.com.

Re: [sage-devel] file reported missing during install

[François Bissey]

Right, I’ll open a ticket for that.

> On 17/05/2022, at 12:11, Matthias Koeppe  wrote:
> 
> It looks like this directory was removed in #27155, so this line can be 
> removed from MANIFEST.in
> 
> 
> On Monday, May 16, 2022 at 4:31:50 PM UTC-7 François Bissey wrote:
> Hi, 
> 
> I have noticed it before but I have only started to wonder about it while 
> preparing the 9.6 release for Gentoo. 
> During the install phase while the wheel is being prepared I have the 
> following messages 
> 
> listing git files failed - pretending there aren't any 
> warning: no files found matching '*.hh' anywhere in distribution 
> warning: no files found matching '*.inc' anywhere in distribution 
> no previously-included directories found matching '.tox' 
> warning: no directories found matching 'sage/libs/gap/test' 
> no previously-included directories found matching 'sage_setup' 
> * Installing the wheel to 
> /var/tmp/portage/sci-mathematics/sage-9.6/work/sagemath-standard-9.6-python3_10/install
>  
> 
> Nothing really surprising except for that “sage/libs/gap/test” directory 
> seemingly coming out of nowhere. 
> 
> Inspecting the source in git, it seems to come from src/MANIFEST.in 
> src/MANIFEST.in:graft sage/libs/gap/test 
> which ultimately is shipped inside the sage math-standard sdist as its 
> regular MANIFEST.in file. 
> Is this something that should be removed or that is actually incorrect? There 
> is no such folder but there are two files called 
> sage/libs/gap/test.py 
> sage/libs/gap/test_long.py 
> in the sources and they are installed as regular python files as part of 
> sagemath-standard. 
> 
> François
> 
> -- 
> 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/d5a4df47-5098-489a-8910-2ddfc656144en%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/41943245-254A-41C0-9902-B47BF0960A91%40gmail.com.

[sage-devel] file reported missing during install

[François Bissey]

Hi,

I have noticed it before but I have only started to wonder about it while 
preparing the 9.6 release for Gentoo.
During the install phase while the wheel is being prepared I have the following 
messages

listing git files failed - pretending there aren't any
warning: no files found matching '*.hh' anywhere in distribution
warning: no files found matching '*.inc' anywhere in distribution
no previously-included directories found matching '.tox'
warning: no directories found matching 'sage/libs/gap/test'
no previously-included directories found matching 'sage_setup'
 *   Installing the wheel to 
/var/tmp/portage/sci-mathematics/sage-9.6/work/sagemath-standard-9.6-python3_10/install

Nothing really surprising except for that “sage/libs/gap/test” directory 
seemingly coming out of nowhere.

Inspecting the source in git, it seems to come from src/MANIFEST.in
src/MANIFEST.in:graft   sage/libs/gap/test
which ultimately is shipped inside the sage math-standard sdist as its regular 
MANIFEST.in file.
Is this something that should be removed or that is actually incorrect? There 
is no such folder but there are two files called
sage/libs/gap/test.py
sage/libs/gap/test_long.py
in the sources and they are installed as regular python files as part of 
sagemath-standard.

François

-- 
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/C3489833-854D-49C2-9AC0-66EB9CB0D875%40gmail.com.

Re: [sage-devel] Proposal: Make "configure --enable-editable" the default in Sage 9.7

[François Bissey]

> On 12/05/2022, at 12:52, Matthias Koeppe  wrote:
> 
> On Wednesday, May 11, 2022 at 5:48:38 PM UTC-7 François Bissey wrote:
> > On 12/05/2022, at 10:54, Matthias Koeppe  wrote: 
> > In https://trac.sagemath.org/ticket/32406 I propose to change the default 
> > installation of Sage to use "configure --enable-editable". 
> 
> My first reaction was that it was a good idea. My view with a bit of 
> reflection is that most devs on this list will want that. 
> But not necessarily end users who just want to use sage.
> 
> End users who do not edit the sources will not notice any difference. 
> 

Then it is certainly the most sensible, because differentiating between develop 
and master is just a disaster waiting to happen.

+1

-- 
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/F77B27A1-0897-4819-9CF3-3C25883E5277%40gmail.com.

Re: [sage-devel] Proposal: Make "configure --enable-editable" the default in Sage 9.7

[François Bissey]

> On 12/05/2022, at 10:54, Matthias Koeppe  wrote:
> 
> In https://trac.sagemath.org/ticket/32406 I propose to change the default 
> installation of Sage to use "configure --enable-editable". 
> This has many benefits for developers: If you only make changes to Python 
> files, there is no need to rebuild ("sage -b"). Just restarting sage picks up 
> the changes.
> The only drawback may be for people who use a workflow that relies on the 
> installed copy of Sage to be isolated from temporary edits by the fact that 
> "sage -b" has not been run yet. (Moving the temporary edits out of the way 
> using "git stash", using "configure --disable-editable", or using a second, 
> stable copy/worktree of Sage are three ways to fix it.)
> Opinions?
> 

My first reaction was that it was a good idea. My view with a bit of reflection 
is that most devs on this list will want that.
But not necessarily end users who just want to use sage.

With that in mind, I think the default should be editable on the development 
branch but non-editable for stable release.
This is a mere opinion and there is certainly space to disagree and further may 
prove unpractical.

François

-- 
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/511A51C0-3EAA-4EEC-9483-BFD721A7C803%40gmail.com.

Re: [sage-devel] Warnings about the current development version are greatly exaggerated

[François Bissey]

This is sage-devel, most people here eat sage unstable for breakfast, may be 
ask in sage-support? But otherwise, yes it is overly scary. It may have been 
justified 10 years ago but not so much now.

> On 2/05/2022, at 07:19, Matthias Koeppe  wrote:
> 
> https://www.sagemath.org/download-latest.html shows a very scary warning 
> "Unstable release for development only. Do not use for your every day work."
> 
> Would there be objections to toning this down a bit?
> 
> 
> 
> -- 
> 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/8e47576c-1c3f-47e1-9e5d-4bb92dc063d6n%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/977C2CEE-F707-412D-A556-945F03BCE41B%40gmail.com.

Re: [sage-devel] [sage-release] Re: Sage 9.5 released

[François Bissey]

Well binary packages are not so well known in Gentoo. But in any case, your 
argument about source distribution applies pretty much to all distro package 
maintainers. At some point they have to choose which options they will enable 
in the build, binary or otherwise, they distribute.

>From what I can see on debian, they try to build for pretty much any options 
>they have available, and those runtime dependencies have to be installed and 
>be included in the dependency tree for that distribution’s binary. Binaries do 
>not magically appear, someone has to build them, a source distribution just 
>make the building the user problem by default, but all distributions have 
>build recipes that you can use yourself if you so wish.

> On 27/04/2022, at 10:56, Matthias Koeppe  wrote:
> 
> On Tuesday, April 26, 2022 at 3:53:46 PM UTC-7 Michael Orlitzky wrote:
> By the same reasoning, Gentoo isn't source-based, 
> because you have the option of installing pre-built binary packages 
> with the default set of options.
> 
> Oh, I didn't know. Haven't met a Gentoo user, only Gentoo developers.
>  
> 
> -- 
> 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/2f321a2a-9b42-4c69-8030-d68ecf2a7264n%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/FD326296-C44B-4417-B598-9A6D636D14BF%40gmail.com.

Re: [sage-devel] unable to access trac.sagemath.org

[François Bissey]

https://downforeveryoneorjustme.com/trac.sagemat.org
says it’s not just you or me.

> On 15/04/2022, at 13:50, Yueqi Li  wrote:
> 
> Hi,
> 
> I'm unable to access trac.sagemath.org. I'm wondering if it's because the 
> website down?
> 
> Sincerely,
> Nicole 
> 
> -- 
> 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/02abaeb7-5dd6-486b-b31e-a2ad32c64c05n%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/57B585DA-25C3-4E91-AD3C-D3D7C29DA9D1%40gmail.com.

Re: [sage-devel] Copy & Paste

[François Bissey]

You do realise that those files under sage/build/pkgs and sage/pkgs are 
actually symlinks to a single instance?

> On 15/04/2022, at 12:25, John H Palmieri  wrote:
> 
> I think your search is following some symbolic links: only three of these 
> instances are under version control (git):
> 
> % git grep 'resolvelinks()'
> sage:resolvelinks() {
> src/bin/sage:resolvelinks() {
> src/bin/sage-env:resolvelinks() {
> 
> The last one should probably have a comment in line with the first two.
> 
> 
> On Thursday, April 14, 2022 at 4:55:08 PM UTC-7 hohoa...@gmail.com wrote:
> Hi,
> 
> 
> Personally, I would rather see the time spent investigating whether or
> not we truly need the symlink-free path in the instances where
> resolvelinks() is currently used. I would guess not -- that there is a
> better solution to whatever other problem prompted the resolvelinks()
> function. But I don't know what that problem was. And to remove the
> function and "see what happens" would be committing yourself to
> answering bug reports from weird sage installs for the next twelve
> months.
> 
> 
> Now your concern is truly appreciated.
> 
>  "Find in File" in "Visual Studio Code" reveals duplications in 24 files in 
> 13 directories (please find the results appended below)
> 
> It is amazing that SageMath is still maintainable up to now,  release 9.6
> Maybe 'resolvelinks' is just  the tip of an iceberg (something more important 
> is missing?)
> 
> Best wishes,
> 
> phiho
> 
> # Query: resolvelinks()
> # ContextLines: 1
> 
> 24 results - 24 files
> 
> sage/sage:
>   32  # meantime however the two should be kept synchronized.
>   33: resolvelinks() {
>   34  # $in is what still needs to be converted (normally has no starting 
> slash)
> 
> sage/build/pkgs/sagelib/src/bin/sage:
>   4  # the top-level "sage" script. Please keep them synchronized.
>   5: resolvelinks() {
>   6  # $in is what still needs to be converted (normally has no starting 
> slash)
> 
> sage/build/pkgs/sagelib/src/bin/sage-env:
>   35  #
>   36: resolvelinks() {
>   37  # $in is what still needs to be converted (normally has no starting 
> slash)
> 
> sage/build/pkgs/sagemath_categories/src/bin/sage:
>   4  # the top-level "sage" script. Please keep them synchronized.
>   5: resolvelinks() {
>   6  # $in is what still needs to be converted (normally has no starting 
> slash)
> 
> sage/build/pkgs/sagemath_categories/src/bin/sage-env:
>   35  #
>   36: resolvelinks() {
>   37  # $in is what still needs to be converted (normally has no starting 
> slash)
> 
> sage/build/pkgs/sagemath_objects/src/bin/sage:
>   4  # the top-level "sage" script. Please keep them synchronized.
>   5: resolvelinks() {
>   6  # $in is what still needs to be converted (normally has no starting 
> slash)
> 
> sage/build/pkgs/sagemath_objects/src/bin/sage-env:
>   35  #
>   36: resolvelinks() {
>   37  # $in is what still needs to be converted (normally has no starting 
> slash)
> 
> sage/pkgs/sage-conf_pypi/sage_root/build/pkgs/sagelib/src/bin/sage:
>   4  # the top-level "sage" script. Please keep them synchronized.
>   5: resolvelinks() {
>   6  # $in is what still needs to be converted (normally has no starting 
> slash)
> 
> sage/pkgs/sage-conf_pypi/sage_root/build/pkgs/sagelib/src/bin/sage-env:
>   35  #
>   36: resolvelinks() {
>   37  # $in is what still needs to be converted (normally has no starting 
> slash)
> 
> sage/pkgs/sage-conf_pypi/sage_root/build/pkgs/sagelib/src/build/scripts-3.10/sage:
>   4  # the top-level "sage" script. Please keep them synchronized.
>   5: resolvelinks() {
>   6  # $in is what still needs to be converted (normally has no starting 
> slash)
> 
> sage/pkgs/sage-conf_pypi/sage_root/build/pkgs/sagelib/src/build/scripts-3.10/sage-env:
>   35  #
>   36: resolvelinks() {
>   37  # $in is what still needs to be converted (normally has no starting 
> slash)
> 
> sage/pkgs/sage-conf_pypi/sage_root/build/pkgs/sagemath_categories/src/bin/sage:
>   4  # the top-level "sage" script. Please keep them synchronized.
>   5: resolvelinks() {
>   6  # $in is what still needs to be converted (normally has no starting 
> slash)
> 
> sage/pkgs/sage-conf_pypi/sage_root/build/pkgs/sagemath_categories/src/bin/sage-env:
>   35  #
>   36: resolvelinks() {
>   37  # $in is what still needs to be converted (normally has no starting 
> slash)
> 
> sage/pkgs/sage-conf_pypi/sage_root/build/pkgs/sagemath_objects/src/bin/sage:
>   4  # the top-level "sage" script. Please keep them synchronized.
>   5: resolvelinks() {
>   6  # $in is what still needs to be converted (normally has no starting 
> slash)
> 
> sage/pkgs/sage-conf_pypi/sage_root/build/pkgs/sagemath_objects/src/bin/sage-env:
>   35  #
>   36: resolvelinks() {
>   37  # $in is what still needs to be converted (normally has no starting 
> slash)
> 
> sage/pkgs/sage-conf_pypi/sage_root/src/bin/sage-env:
>   35  #
>   36: resolvelinks() {
>   37 

Re: [sage-devel] Trouble with SSH access

[François Bissey]

I can’t help but notice that part of the message:
“Warning: Identity file /Users/yueqili/.ssh/ssh_key-sage-trac-2 not accessible: 
No such file or directory.”
Are you sure that it is the right file name?

François

> On 11/04/2022, at 07:23, L Nicole  wrote:
> 
> Hi,
> 
> I have the same issue too. I'm not able to use git trac push, it shows that 
> Permission is denied (publickey).
> 
> Sincerely,
> Nicole
> 
> 
> 
> On Thursday, April 7, 2022 at 11:39:11 AM UTC-4 antoine@gmail.com wrote:
> Hi,
> 
> I created a pair of ec25519 SSH keys to access Trac through SSH (see 
> https://doc.sagemath.org/html/en/developer/trac.html#trac-authentication-through-ssh).
>  The key identity file is ~/.ssh/ssh_key-sage-trac-2. I am using Ubuntu 21.10 
> However, my config does not seem to work:
> 
> $ ssh -i ~/.ssh/ssh_key-sage-trac-2 g...@trac.sagemath.org info
> g...@trac.sagemath.org: Permission denied (publickey).
> 
> I can share a more verbose log (with confidential information deleted) if 
> necessary.
> 
> I read that this could be related to the comment in the key, but I tried 
> several possibilities (no spaces, no comment, with spaces, etc).
> 
> I looked through many discussions in this group about this problem (e.g. 
> https://groups.google.com/g/sage-devel/c/RArcnGt0i6E/m/JNo4__dmBAAJ), but I 
> could not find any solution. Does anybody have any idea?
> 
> Thanks,
> Antoine
> 
> -- 
> 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/65a1f3fa-9a8b-4c63-a8e7-195c21152ccdn%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/5AF700E8-2281-4AF0-9A08-14F2636F42DD%40gmail.com.

Re: [sage-devel] Pytest is not detected by sage

[François Bissey]

The way they want to run pytest, I would suggest to try
cd src
pytest -v 
first. The configuration files for pytest are in there and it should be the 
reported rootdir. Not SAGE_ROOT.

> On 24/03/2022, at 22:41, Dima Pasechnik  wrote:
> 
> you need Sage's pytest package, which can be installed by doing e.g. 
> 
> make pytest
> 

-- 
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/FA978C5B-C47C-47A4-9A11-A3CE83BBD19B%40gmail.com.

[sage-devel] restoring verbosity for building sagelib

[François Bissey]

Hi all,

In the old day the sagelib was outputting all the compiling and linking 
commands during builds.
In the last few months, it only display progress messages and warnings from the 
compiler and linker.
Is there a way to have the verbosity back? There are times where you want to 
inspect the issued commands even if they don’t fail.

Cheers,
François

-- 
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/611EF04D-3F20-422A-8CCF-80AFAA8ECFD3%40gmail.com.

Re: [sage-devel] Error: failed to extract /home/linethan0322/sage-9.5.rc4/upstream/gap-4.11.1.tar.gz

[François Bissey]

>From your log
OSError: [Errno 28] No space left on device

You’ve run out of disk. Nothing we can do about that :)
 
> On 9/03/2022, at 08:25, Ethan Lin  wrote:
> 
> Hello! I have encountered an error while making/upgrading sage,
> The sage version is 9.6.beta4
> My OS is Debian Bookworm (testing)
> make[4]: *** [Makefile:2757: gap-SAGE_LOCAL-no-deps] Error 1
> make[3]: *** [Makefile:2757: 
> /home/linethan0322/sage-9.5.rc4/local/var/lib/sage/installed/gap-4.11.1] 
> Error 2
> make[2]: *** [Makefile:2461: all-start] Error 2
> 
> real0m56.405s
> user0m38.218s
> sys 0m12.248s
> ***
> Error building Sage.
> 
> The following package(s) may have failed to build (not necessarily
> during this run of 'make all-start'):
> 
> * package: gap-4.11.1
>   last build time: Mar 8 14:20
> 
> -- 
> 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/bb7f2414-a00f-4a84-a73c-0feb9aae7f2dn%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/17033B69-2E43-4DC7-9BDD-96818FA70D8F%40gmail.com.

Re: [sage-devel] Unable to build ecl-16.1.2.p5 on Ubuntu 20.04 LTS

[François Bissey]

Any reason you are sticking to sage 9.0 when 9.5 is out?

> On 7/03/2022, at 10:27, Alexander Rahm  wrote:
> 
> This workaround fails on my computer:
> 
> Using 
> ./configure --without-system-libffi
> make
> 
> I however run into the same crash.
> 
> Best,
> 
> Alexander
> 
> [ecl-16.1.2.p5] make[6]: *** [Makefile:86: ffi.o] Error 1
> [ecl-16.1.2.p5] make[6]: Leaving directory 
> '/home/rahm/sage-9.0/local/var/tmp/sage/build/ecl-16.1.2.p5/src/build/c'
> [ecl-16.1.2.p5] make[5]: *** [Makefile:119: libeclmin.a] Error 2
> [ecl-16.1.2.p5] make[5]: Leaving directory 
> '/home/rahm/sage-9.0/local/var/tmp/sage/build/ecl-16.1.2.p5/src/build'
> [ecl-16.1.2.p5] make[4]: *** [Makefile:70: all] Error 2
> [ecl-16.1.2.p5] make[4]: Leaving directory 
> '/home/rahm/sage-9.0/local/var/tmp/sage/build/ecl-16.1.2.p5/src'
> [ecl-16.1.2.p5] 
> [ecl-16.1.2.p5] Error building ecl-16.1.2.p5
> [ecl-16.1.2.p5] 
> [ecl-16.1.2.p5] 
> [ecl-16.1.2.p5] real1m15.084s
> [ecl-16.1.2.p5] user0m56.136s
> [ecl-16.1.2.p5] sys0m12.399s
> [ecl-16.1.2.p5] 
> 
> [ecl-16.1.2.p5] Error installing package ecl-16.1.2.p5
> [ecl-16.1.2.p5] 
> 
> [ecl-16.1.2.p5] Please email sage-devel 
> (http://groups.google.com/group/sage-devel)
> [ecl-16.1.2.p5] explaining the problem and including the log file
> [ecl-16.1.2.p5]   /home/rahm/sage-9.0/logs/pkgs/ecl-16.1.2.p5.log
> [ecl-16.1.2.p5] Describe your computer, operating system, etc.
> [ecl-16.1.2.p5] If you want to try to fix the problem yourself, *don't* just 
> cd to
> [ecl-16.1.2.p5] /home/rahm/sage-9.0/local/var/tmp/sage/build/ecl-16.1.2.p5 
> and type 'make' or whatever is appropriate.
> [ecl-16.1.2.p5] Instead, the following commands setup all environment 
> variables
> [ecl-16.1.2.p5] correctly and load a subshell for you to debug the error:
> [ecl-16.1.2.p5]   (cd 
> '/home/rahm/sage-9.0/local/var/tmp/sage/build/ecl-16.1.2.p5' && 
> '/home/rahm/sage-9.0/sage' --sh)
> [ecl-16.1.2.p5] When you are done debugging, you can type "exit" to leave the 
> subshell.
> [ecl-16.1.2.p5] 
> 
> make[3]: *** [Makefile:2152: 
> /home/rahm/sage-9.0/local/var/lib/sage/installed/ecl-16.1.2.p5] Error 1
> make[3]: Leaving directory '/home/rahm/sage-9.0/build/make'
> make[2]: *** [Makefile:1830: all-start] Error 2
> make[2]: Leaving directory '/home/rahm/sage-9.0/build/make'
> 
> real33m55.541s
> user26m18.407s
> sys2m1.880s
> ***
> Error building Sage.
> 
> The following package(s) may have failed to build (not necessarily
> during this run of 'make all-start'):
> 
> * package: ecl-16.1.2.p5
>   log file: /home/rahm/sage-9.0/logs/pkgs/ecl-16.1.2.p5.log
>   build directory: /home/rahm/sage-9.0/local/var/tmp/sage/build/ecl-16.1.2.p5
> 
> The build directory may contain configuration files and other potentially
> helpful information. WARNING: if you now run 'make' again, the build
> directory will, by default, be deleted. Set the environment variable
> SAGE_KEEP_BUILT_SPKGS to 'yes' to prevent this.
> 
> make[1]: *** [Makefile:33: all-start] Error 1
> make[1]: Leaving directory '/home/rahm/sage-9.0'
> make: *** [Makefile:13: all] Error 2
> 
> dim...@gmail.com schrieb am Freitag, 1. Mai 2020 um 03:02:10 UTC-5:
> On Fri, May 1, 2020 at 8:34 AM Andrew Bernard  wrote: 
> > 
> > Ah, not so fast. More testing revealed that if you remove the Ubuntu 
> > package libffi-dev, or perhaps don't install it in the first place a full 
> > clean compile results. 
> > 
> > That's good news. 
> > 
> > I would therefore say that Ubuntu 20.04 LTS is a viable platform. This was 
> > built from the sage-9.0 source tar file from the mirrors. 
> > 
> 
> As 20.04 LTS it was released much later than Sage 9.0, there could be 
> no guarantees that the latter would work there. 
> If it works, great, if it does not, that's is a platform problem 
> rather than a Sage 9.0 problem. 
> 
> Based on your report, I suppose a canonical way to build would be 
> 
> ./configure --without-system-libffi 
> make 
> 
> 
> 
> 
> 
> > 
> > On Friday, 1 May 2020 15:05:26 UTC+10, Matthias Koeppe wrote: 
> >>> 
> >>> 
> >>> Sage 9.0 does not build on Ubuntu 20. You will have to try a current 
> >>> development version. 
> >>> 
> >> 
> >> I have added this information to the page 
> >> https://wiki.sagemath.org/ReleaseTours/sage-9.0 ("Installation FAQ"). 
> >> 
> > -- 
> > 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 

Re: [sage-devel] Building from develop fails in OS X Big Sur

[François Bissey]

It looks like several things not going well. The first and most obvious one is 
that libntl doesn’t seem to be found. Some of the other stuff may be related to 
gmp. ntl is definitely found by configure but the location of the library is 
not passed with `-L` to giac and eclib at least. So I think some stuff you are 
getting from brew (I am assuming it is brew) is not setup properly for sage 
build. 

> On 2/03/2022, at 21:23, Niranjan M  wrote:
> 
> Hi I am trying to build from the develop branch and I am getting this error 
> for few packages like (giac-1.6.0.47p3, eclib-20210625, givaro-4.1.1, 
> lcalc-2.0.5) 
> ld: symbol(s) not found for architecture x86_64
> Thanks for the help.
> 
> -- 
> 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/0d101b40-47f0-44ac-8a61-6df56e2aaf86n%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/1802F473-55B1-4E8E-AF3A-0E91BE226A94%40gmail.com.

Re: [sage-devel] Error configuring brial-1.2.8

[François Bissey]

HI Kotaro,

yes, it looks like the list of dependencies for trial is slightly incorrect 
since brial uses pkg-config to detect m4ri.
We’ll need to open a bug on trac for this.

François

> On 26/02/2022, at 01:15, Kotaro Nishida  wrote:
> 
> Greetings,
> 
> I am installing sage but I can't solve this error
> 
> =
> configure: error: in 
> `/home/kouta/sage-9.5/local/var/tmp/sage/build/brial-1.2.8/src':
> configure: error: The pkg-config script could not be found or is too old.  
> Make sure it
> is in your PATH or set the PKG_CONFIG environment variable to the full
> path to pkg-config.
> 
> 
> 
> 
> 
> Please give me some advise.
>  
> 
> $uname -a
> Linux DESKTOP-53KTEU1 4.4.0-19041-Microsoft #1237-Microsoft Sat Sep 11 
> 14:32:00 PST 2021 x86_64 x86_64 x86_64 GNU/Linux
> 
> Thank you for your help.
> 
> Regards,
> 
> Kotaro
> 
> 
> -- 
> 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/d828c20d-f5fa-4852-a4a7-17baae850c0bn%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/7DFFD8A4-95B3-484C-A47F-F1129CD59B96%40gmail.com.

Re: [sage-devel] Moving SAGE_TMP to the system location

[François Bissey]

> On 14/02/2022, at 03:57, Michael Orlitzky  wrote:
> 
> If not, I'm proposing we,
> 
>  1. Replace all direct uses of SAGE_TMP in library/doctest code with 
> python's tempfile module.
>  2. Drop SAGE_TMP from tmp_filename() and tmp_dir(); this will revert
> to whatever directory the OS uses.
>  3. Slowly migrate away from tmp_filename() and tmp_dir() to the 
> functions that python provides.

+1

-- 
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/463E6DED-39AB-44DA-8869-C26F02255851%40gmail.com.

Re: [sage-devel] trouble pushing to a ticket

[François Bissey]

Just so you don’t feel alone, it happened to me earlier this month. I almost 
posted before googling the error. I have now replaced my 11 years old ssh key 
by a shinny new one.

> On 20/01/2022, at 18:25, Steven Trogdon  wrote:
> 
> Didn't mean to send a private email. This worked, thanks. I was aware of the 
> change but didn't realize the extent. Thanks again.
> 
> On Wednesday, January 19, 2022 at 10:09:42 PM UTC-7 Michael Orlitzky wrote:
> On Wed, 2022-01-19 at 21:04 -0800, Steven Trogdon wrote: 
> > I'm having difficulty pushing to a ticket, which I've done many times 
> > previously. When I push, i.e. 
> > 
> > 
> 
> OpenSSH 8.8 (recently stable on Gentoo) disables RSA with SHA-1. You 
> can work around it, but probably the best long-term solution is to 
> replace your RSA key with an ECDSA one (ssh-keygen -t ecdsa) and re- 
> upload it to trac. 
> 
> 
> 
> -- 
> 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/2110484e-b8a4-4ceb-8311-e1b1c946331bn%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/28B0D0B7-201C-4992-B3E8-B994907AD869%40gmail.com.

Re: [sage-devel] Dependence of RealDoubleElement on GSL

[François Bissey]

After looking a bit at gsl’s doc I don’t think there is any advantage to using 
them if we are not using the error handling and reporting of gsl (by that I 
mean error estimates on the results). The only interesting detail is, quoting, 
“consistency across platforms”. If we are not doing high precision, I don’t 
think we should care too much on the kind of differences we should expect from 
C libraries across platforms.

> On 13/10/2021, at 09:45, Matthias Koeppe  wrote:
> 
> Elements of RealDoubleField (RDF) have some methods that are implemented 
> using GSL.
> 
> Would we be able to eliminate this dependency? Some of the functions, like 
> isnan, are available in the standard C library since C99. Do functions like 
> gsl_sf_sin have advantages over using functions from the math library? 
> Others, for example gsl_sf_erf, would be available through scipy.special.
> 

-- 
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/B77FB2A7-480A-4CFC-870E-3CBD05885540%40gmail.com.

Re: [sage-devel] How to modularize for fun and profit, II: MONOREPO vs. MULTIREPO

[François Bissey]

Another fact that annoys me about monorepo is the versioning of the components. 
There is no right or wrong here, just preferences.

In the monorepo scenario you’ll have subcomponents released and they (usually) 
will all have matching version numbers.
This is easy to figure out what you should use :) that’s good
Sometimes there will be a new release of some component where the only thing 
changing is the version number :( this is a bit of a waste.

Going monrepo you may maintain a version number coherence and over-release some 
components.
Going multirepo may mean decoupling those version numbers, as you only cut a 
release when there is something new to release in a subcomponent.

I am personally on the multiple repo side and decoupling of version numbers. 
But I appreciate the coherence of having a single version number to refer too.

-- 
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/5F867FEB-174A-4970-B1E4-DC0E993A0374%40gmail.com.

Re: [sage-devel] How to modularize for fun and profit, II: MONOREPO vs. MULTIREPO

[François Bissey]

> On 11/10/2021, at 15:07, Matthias Koeppe  wrote:
> 
> On Sunday, October 10, 2021 at 5:49:05 PM UTC-7 François Bissey wrote:
> To package these I pull the full tree :( and then I don’t go to 
> SAGE_ROOT/pkgs/pkg_name and build from there. 
> If I want to patch it doesn’t work from there because patch doesn’t apply 
> across symbolic links. So, instead I go to SAGE_ROOT/src, copy the 
> appropriate setup.py (and any other files needed) and patch and build from 
> there. 
> 
> This sounds terrible. If you want to maintain a patch-based workflow against 
> the sdists, why not generate the sdists and patch them?
> 

I need to implement some automation for that. To make sure I am not surprised 
by new things I usually follow Volker’s merging tree (this happen on a branch 
of the sage-on-too repo that isn’t publicised). I’d need to get new sdists each 
time he pushes, this is feasible but not in my current expertise.
For releases, falling back to pipy sdists should be trivial, beta and rc I 
would need to go back to release stuff separately, which I stopped doing almost 
10 years ago because it was easier to just have a “live ebuild” following the 
develop branch on GitHub for monolithic builds.

François 

-- 
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/C3AFFE15-0B28-45DE-934A-397E7AFBB2A3%40gmail.com.

Re: [sage-devel] How to modularize for fun and profit, II: MONOREPO vs. MULTIREPO

[François Bissey]

> On 11/10/2021, at 15:02, Matthias Koeppe  wrote:
> 
> On Sunday, October 10, 2021 at 5:49:05 PM UTC-7 François Bissey wrote:
> For proper releases, I am hoping for separate tarballs (eventually) which 
> means that there won’t be any issues with symbolic links.
> 
> Anyone can create the package tarballs by just using "setup.py sdist" in the 
> distribution package directories in the checked out and bootstrapped 
> repository.
> This is also what I do when I upload the distributions to PyPI.
> 
> https://trac.sagemath.org/ticket/29039 (needs review) adds the command "make 
> pypi-sdists", which does this for all the distributions.
> 
> https://trac.sagemath.org/ticket/32062 is for adding this (and publishing to 
> PyPI) as an automatic step on GH Actions. 
> 

I am presuming the upload will be automatic for releases and may also for beta 
and rc?

François

-- 
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/9FCB2504-82B6-4476-B7BE-4F37B60A3556%40gmail.com.

Re: [sage-devel] How to modularize for fun and profit, II: MONOREPO vs. MULTIREPO

[François Bissey]

> On 11/10/2021, at 14:00, William Stein  wrote:
> 
> On Sun, Oct 10, 2021 at 5:49 PM François Bissey  wrote:
>> 
>> One annoying thing about monorepo from a downstream perspective - but only 
>> for people crazy enough to package a development branch (OK that would be me 
>> and not many other people :) ).
>> The split packages have their setup.py or equivalent in 
>> SAGE_ROOT/pkgs/pkg_name and some links to the single sage source tree from 
>> there. Examples: sagemath-standard, sage_setup and sage_docbuild. To package 
>> these I pull the full tree :( and then I don’t go to SAGE_ROOT/pkgs/pkg_name 
>> and build from there.
> 
> I don't understand what you're doing.  However, I just want to point
> out that it is possible to use Git to only pull a selected directory
> (or directories) from a Git repo with no history. See, e.g., the
> discussion of "sparse checkout" here.
> 
> https://stackoverflow.com/questions/600079/how-do-i-clone-a-subdirectory-only-of-a-git-repository

I don’t know if it can be used inside Gentoo ebuilds but this is an interesting 
thing to be able to do. I will certainly explore that possibility but if it 
doesn’t replace symlinks in a particular subdirectory it may all be in vain.

François

-- 
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/534BA612-52E0-4ECD-A33E-F964ED9F9F40%40gmail.com.

Re: [sage-devel] How to modularize for fun and profit, II: MONOREPO vs. MULTIREPO

[François Bissey]

One annoying thing about monorepo from a downstream perspective - but only for 
people crazy enough to package a development branch (OK that would be me and 
not many other people :) ).
The split packages have their setup.py or equivalent in SAGE_ROOT/pkgs/pkg_name 
and some links to the single sage source tree from there. Examples: 
sagemath-standard, sage_setup and sage_docbuild. To package these I pull the 
full tree :( and then I don’t go to SAGE_ROOT/pkgs/pkg_name and build from 
there.
If I want to patch it doesn’t work from there because patch doesn’t apply 
across symbolic links. So, instead I go to SAGE_ROOT/src, copy the appropriate 
setup.py (and any other files needed) and patch and build from there. To patch 
while setting the top package source tree at SAGE_ROOT/pkg/pkg_name I would 
have to write my own new patching machinery for Gentoo ebuilds - not gonna 
happen.
That wouldn’t happen with split repos.
For proper releases, I am hoping for separate tarballs (eventually) which means 
that there won’t be any issues with symbolic links. 

François

> On 11/10/2021, at 13:17, Matthias Koeppe  wrote:
> 
> As we are making progress on preparing the Sage library for modularization 
> (https://trac.sagemath.org/ticket/29705), here's a discussion of three things 
> that need to be decided whenever a portion of the Sage library is modularized:
> 
> (1) Namespace: Will it be imported as (+) "from sage.hermeneutics.quantum 
> import QuantumGravity" or (-) "from transformative_hermeneutics.quantum 
> import QuantumGravity"?
> 
> (2) Distribution name (= project name): Will it be installed using "pip 
> install transformative-hermeneutics" or "pip install sagemath-hermeneutics"?
> 
> (3) Source repository: Is the source maintained as part of the Sage 
> repository using Trac tickets (MONOREPO); or in a separate repository on 
> GitHub, GitLab, ... (MULTIREPO)?
> 
> This post is dedicated to the MONOREPO vs. MULTIREPO question, and how it 
> relates to (1) and (2). 
> 
> Some details about MONOREPO:
> The Sage repository already contains several separate distribution source 
> trees. Since Sage 9.4 they are located in the subdirectory SAGE_ROOT/pkgs 
> (see 
> https://wiki.sagemath.org/ReleaseTours/sage-9.4#New_location_for_distribution_package_sources:_SAGE_ROOT.2Fpkgs).
> For example, SAGE_ROOT/pkgs/sage-sws2rst is a self-contained source tree of 
> this distribution package: It has standard Python packaging files such as 
> setup.py.
> SAGE_ROOT/pkgs/sagemath-standard is also a source tree of this distribution 
> package; but it is created in part using symbolic links into SAGE_ROOT/src. 
> This is the trick that has allowed the modularization effort to keep the 
> SAGE_ROOT/src tree monolithic: Modularization has been happening behind the 
> scenes and will not change where Sage developers find the source files.
> 
> In favor of MONOREPO:
> + The Sage developer community is used to using Trac
> + The process is well defined: No code "ownership" (all Sage developers can 
> change any code, subject to peer review); changes are synchronized
> + There is implicit integration testing with all of Sage
> 
> Drawbacks of MONOREPO:
> - Extra hurdle for attracting new developers from outside the Sage developer 
> community (everyone who is not already a Sage developer uses GitHub or 
> similar)
> - Testing infrastructure needs to be set up and maintained separately; in 
> particular, integration testing with Sage.
> 
> Evidence:
> - The pynac situation -- now finally resolved by merging it into the Sage 
> library 
> (https://wiki.sagemath.org/ReleaseTours/sage-9.5#Modularization_and_packaging_changes)
> - Even for separate git repositories hosted in the SageMath GitHub 
> organization (https://github.com/sagemath/), code ownership and review 
> workflow are unclear.
>   - For example, https://github.com/sagemath/sage-numerical-backends-coin 
> provides no information on how to contribute (commonly expected in a file 
> CONTRIBUTING.md)
>   - Neither does https://github.com/sagemath/cysignals, which moreover looks 
> abandoned: Issues and PRs are not tended to. Is it subject to peer review 
> like other parts of Sage? Who is in charge of merging PRs?
>   - Similar issues with https://github.com/sagemath/cypari2
> 
> 
> Recommendation: Keep MONOREPO for all distributions that fill the 
> sage.PAC.KAGE.MODULE namespace (= distribution packages named sagemath-... -- 
> according to my recommendation in part I). 
> 
> Recommendation: For distributions that do not use the sage.PAC.KAGE.MODULE 
> namespace (= distribution packages named something other than sagemath-... -- 
> according to my recommendation in part I), weigh the benefits vs. drawbacks 
> of MONOREPO vs. MULTIREPO. It is also simple enough for a distribution to 
> start out being developed inside of the Sage MONOREPO and to be split out to 
> a separate repository later.
> 
> Recommendation: Discuss the development workflow for projects in the 
> 

Re: [sage-devel] #32532 - removing gcc and gfortran spkgs

[François Bissey]

I have at least one close user/tester that builds sage-on-gentoo on a gentoo 
prefix (on a debian machine I think). Pretty much every beta/rc release get 
built and tested.
I used to work on gentoo-prefix on OS X for a while. I should try it again 
someday but I don’t feel like my little macbook pro is a suitable environment 
for the kind of always compiling that ends up happening if you are doing 
serious development rather than just installing it every once in a while to use 
it.

By the way switching to clang+gfortran-spkg over the gcc-spkg shaved 3 hours of 
building time of vanilla sage on my previous macbook. That was what took the 
most time to build by a very wide margin. 

> On 24/09/2021, at 16:18, Matthias Koeppe  wrote:
> 
> Gentoo is not relocatable, so that would not be useful. gentoo-prefix is 
> hardly production-ready last time I checked 
> (https://trac.sagemath.org/ticket/29105), and there is no evidence anyone has 
> ever built Sage on it.
> 

François

-- 
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/BDB7C84C-D6FB-4C8F-8CF6-8ED8EE9104AA%40gmail.com.

Re: [sage-devel] #32532 - removing gcc and gfortran spkgs

[François Bissey]

> On 24/09/2021, at 13:12, Matthias Koeppe  wrote:
> 
> c) The use of any Fortran compiler other than homebrew's packaging of 
> gfortran on macOS (and our gfortran spkg) is completely unexplored. Given the 
> instability of homebrew -- as a rolling platform on which it is not possible 
> to install a specific version, it would be reckless to tie ourselves to 
> homebrew's gfortran as the only option. (An effort to support macports in 
> https://trac.sagemath.org/ticket/31505 is stalled.)
> 

For the nitpick record.

This is not completely unexplored but I haven’t poured any activity there for 
months due to “too many things to do and not enough of me to go around”. I 
actually  actively explored using alternative compiler (c/c++ and fortran).

Apart from sqlite that was detecting intrinsics in a stupid fashion at the 
time, sage did build with the intel C/C++ compiler but pari optimisation had to 
be turned off completely (pari compiled with -O0 or completely broken - no 
joke).

sage did build with the pgfortran (now nvfortran compiler) once an issue in 
openblas was fixed [I believe my fix made it upstream].

I don’t have a clear memory of the result with the intel fortran compiler, but 
I usually remember difficulties so I am going to assume there was none.

Optional packages were not covered in those exercises.

François

-- 
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/CA06CD26-E732-4DB2-B71A-341639EDBD92%40gmail.com.

Re: [sage-devel] #32532 - removing gcc and gfortran spkgs

[François Bissey]

As someone who contributed to those (and literally created the gfortran package 
when I pushed for enabling clang support on OS X) I welcome their demise. I’ll 
review their removal with pleasure if you need it.

François

> On 24/09/2021, at 10:17, Dima Pasechnik  wrote:
> 
> https://trac.sagemath.org/ticket/32532 proposes to remove these packages as 
> not needed, and a huge time sink for everyone involved.
> 
> Rationale: nowadays every platform that Sage supports has said tools (or 
> their equivalents - e.g. clang/clang++ in case of macOS and FreeBSD) 
> available, if not outright as a system package, but surely with a very 
> minimal effort.
> 
> There is no need to carry this baggage forward.
> Moreover, it seems that Sage  is the only Python library/platform around 
> which (potentially) vendors gcc/g++/gfortran. 
> 
> 
> 
> -- 
> 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/CAAWYfq0hsaf3SR-78Wajb_OdYjZq1MyReRH2vcwSO%2BU7CzLtYw%40mail.gmail.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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/7C219AEF-FD68-4D19-B31F-1115FFAA5BB3%40gmail.com.

Re: [sage-devel] pari: config file location changed on Fedora

[François Bissey]

OK, it is a big issue. cypari2 relies on that result to find pari.cfg. And this 
is where all pari packages are supposed to be installed.
I am not what is so much more standard to have stuff about your package inside 
/usr/lib{,64}/$pkg. If you really want to make a point for a standard place I 
would have put it under /etc.

François

> On 9/08/2021, at 12:28, Kazuyoshi Furutaka  
> wrote:
> 
> $ gp
> Reading GPRC: /etc/gprc
> GPRC Done.
> 
>   GP/PARI CALCULATOR Version 2.13.2 (released)
>   amd64 running linux (x86-64/GMP-6.2.0 kernel) 64-bit version
> compiled: Jul 16 2021, gcc version 11.1.1 20210531 (GCC)
>threading engine: pthread
>  (readline v8.1 enabled, extended help enabled)
> 
>  Copyright (C) 2000-2020 The PARI Group
> 
> PARI/GP is free software, covered by the GNU General Public License, and 
> comes 
> WITHOUT ANY WARRANTY WHATSOEVER.
> 
> Type ? for help, \q to quit.
> Type ?17 for how to get moral (and possibly technical) support.
> 
> parisize = 800, primelimit = 50, nbthreads = 8
> ? print(default(datadir))
> /usr/share/pari
> ? 
> 
> Goodbye!
> 
> 
> 2021年8月9日月曜日 9:07:43 UTC+9 François Bissey:
> This is really an issue to build cypari2. Could you give us the result of the 
> following: 
> * start gp by typing 
> gp 
> * at the gp prompt enter 
> print(default(datadir)) 
> * and send us the result. 
> You can use ctrl+d to exist the gp session. 
> 
> François 
> 
> > On 9/08/2021, at 11:46, Kazuyoshi Furutaka  wrote: 
> > 
> > 
> > Dear sage experts... 
> > 
> > I'm sorry not to show the fix and only to report. 
> > The location of pari.cfg has been changed recently and 
> > `--with-system-pari=no` is in need to configure latest sage (9.4.rc[01]). 
> > 
> > $ rpm -q --changelog pari|head -3 
> > * Fri Jul 16 2021 Jerry James  - 2.13.2-2 
> > - Install the config file in a more standard location 
> > 
> > $ locate pari.cfg | grep usr 
> > /usr/lib64/pari/pari.cfg 
> > 
> > $ cat /etc/fedora-release 
> > Fedora release 34 (Thirty Four) 
> > 
> > Thanks. 
> > Kazuyoshi 
> > 
> > -- 
> > 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/1e5b4dde-dd45-43f9-9efb-5574776c1a71n%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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/f720196a-f466-415c-a7a1-28b974e95d01n%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/021E2346-DA78-4064-9C7B-E0710B4D0F4D%40gmail.com.

Re: [sage-devel] pari: config file location changed on Fedora

[François Bissey]

This is really an issue to build cypari2. Could you give us the result of the 
following:
* start gp by typing
gp
* at the gp prompt enter
print(default(datadir))
* and send us the result.
You can use ctrl+d to exist the gp session.

François

> On 9/08/2021, at 11:46, Kazuyoshi Furutaka  
> wrote:
> 
> 
> Dear sage experts...
> 
> I'm sorry not to show the fix and only to report.
> The location of pari.cfg has been changed recently and 
> `--with-system-pari=no` is in need to configure latest sage (9.4.rc[01]).
> 
> $ rpm -q --changelog pari|head -3
> * Fri Jul 16 2021 Jerry James  - 2.13.2-2
> - Install the config file in a more standard location
> 
> $ locate pari.cfg | grep usr
> /usr/lib64/pari/pari.cfg
> 
> $ cat /etc/fedora-release 
> Fedora release 34 (Thirty Four)
> 
> Thanks.
> Kazuyoshi
> 
> -- 
> 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/1e5b4dde-dd45-43f9-9efb-5574776c1a71n%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/E359FFB5-01A9-41C6-9FC8-847F76804884%40gmail.com.

Re: [sage-devel] Proposal: Making cmake a standard package

[François Bissey]

+1

> On 17/07/2021, at 09:26, Samuel Lelievre  wrote:
> 
> +1
> 
> -- 
> 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/9a0f6632-327b-478e-aa0c-417fc87ba438n%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/C27ACA8C-38DA-4CC7-A0B8-F1B9BDA65A97%40gmail.com.

Re: [sage-devel] pynac fails to build (sage 9.4.beta4, clang)

[François Bissey]

Yeah, I turned it off on a previous machine after a funny replacement of lapack.

> On 10/07/2021, at 22:57, Samuel Lelievre  wrote:
> 
> With some effort these engines can actually be turned off.
> 

-- 
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/69F842A8-63F3-4CC0-AF81-DD6D46B8FA43%40gmail.com.

Re: [sage-devel] pynac fails to build (sage 9.4.beta4, clang)

[François Bissey]

Should be solved by the move to penal-0.7.29. This is the same kind of errors 
that I fixed for g++11.

> On 10/07/2021, at 08:06, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
> 
> Dear all,
> 
> I am not able to build pynac with clang because of the error
> 
>  error: no member named 'numeric_limits' in namespace 'std'
> 
> See attached log for details.
> 
> Best
> Vincent
> 
> -- 
> 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/540271c4-9899-34db-9064-b414e37d9a9c%40gmail.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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/825E7CDC-8485-4ADF-BB8F-D59EA2F5F0E1%40gmail.com.

Re: [sage-devel] problem building maxima

[François Bissey]

It looks like maxima.fas has not been built. Last time I saw that happen
in sage-on-gentoo was because the patch to build it was missing.
Not sure how it could happen on your setup, the log needs further inspection.

> On 14/05/2021, at 21:18, John Cremona  wrote:
> 
> I have been installing sage-9.3 from the tarball on a few ubuntu
> machines, just doing ./configure and then make.  On one machine
> running ubuntu 20.04.02 LTS maxima fails to build.  I have attached
> the log files.
> 
> This is a machine on which I tried a few weeks ago to help the build
> process by installing as many of the dependencies as possible.  My
> experience so far has been that this has caused so many things to go
> wrong that I prefer the old way -- build everything -- since that just
> takes more computer time, while the new way (so far) uses a lot more
> of my time.
> 
> John
> 
> -- 
> 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/CAD0p0K7VWKz7ActzBjT9FZdW_yo3bkK99bSDEWd0n-zWkQsyNw%40mail.gmail.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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/7DE9A1AD-82F1-4058-B34A-A02C00E6950D%40gmail.com.

Re: [sage-devel] Proposal: Very short release cycle for Sage 9.4

[François Bissey]

I guess I could whip up a branch quickly since we know the things that have to 
be done overall.
I would prefer if we had a new pynac release rather than continue pilling 
patches.

François

> On 11/05/2021, at 11:00, 'Travis Scrimshaw' via sage-devel 
>  wrote:
> 
> +1 on this. I know many people who use the latest OSX.
> 
> Best,
> Travis
> 
> 
> On Tuesday, May 11, 2021 at 5:09:55 AM UTC+10 Matthias Koeppe wrote:
> ... with a focus on adding support for gcc/gfortran 11 
> (https://trac.sagemath.org/ticket/31786)
> and in particular fixing the build on macOS Big Sur with homebrew that was 
> broken by homebrew's upgrade to gcc 11 
> (https://trac.sagemath.org/ticket/29703).
> 
> 
> 
> 
> -- 
> 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/56a30dd5-cee3-4b1a-9198-d898ca15743dn%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/40413B9A-AAD6-4CB9-8F74-E252CDAA3E1A%40gmail.com.

Re: [sage-devel] [abi:cxx11] in givaro prevents linking to system givaro on Fedora 32

[François Bissey]

Interestingly on Gentoo I currently have both symbols
fbissey@moonloop ~ $ nm -D /usr/lib64/libgivaro.so.9.1.1 | grep 
_ZNK6Givaro7IntegercvNSt7__cxx1112basic_stringIcSt11char | c++filt -n
000180b0 T Givaro::Integer::operator std::__cxx11::basic_string, std::allocator >[abi:cxx11]() const
000180b0 T Givaro::Integer::operator std::__cxx11::basic_string, std::allocator >() const

Last compile was with gcc-11.1.0

> On 8/05/2021, at 23:34, François Bissey  wrote:
> 
> What compiler and flags have used to compile fedora 32 givaro? Can we easily 
> find out?
> 
>> On 8/05/2021, at 23:31, Dima Pasechnik  wrote:
>> 
>> With system Givaro, one gets
>> 
>> [dochtml] ImportError: 
>> /home/scratch2/dimpase/sage/sage/local/lib64/python3.8/site-packages/sage/matrix/matrix_modn_sparse.cpython-38-x86_64-linux-gnu.so:
>>  undefined symbol: 
>> _ZNK6Givaro7IntegercvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEB5cxx11Ev
>> make[3]: *** [Makefile:2280: doc-html] Error 1
>> 
>> which demangled says
>> 
>> $ c++filt 
>> _ZNK6Givaro7IntegercvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEB5cxx11Ev
>> Givaro::Integer::operator std::__cxx11::basic_string> std::char_traits, std::allocator >[abi:cxx11]() const
>> 
>> The system library has Givaro::Integer::operator 
>> std::__cxx11::basic_string, 
>> std::allocator >() const
>> 
>> (no of that weird [abi:cxx11] qualifier)
>> 
>> Any ideas how to fix this? (besides not using system Givaro) ?
>> 
>> Dima
>> 
>> -- 
>> 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/b187faf3-50c4-42c4-ae37-77c5a3902bbcn%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/96717AEA-F818-447E-98D6-3132A5CFC8FC%40gmail.com.

Re: [sage-devel] [abi:cxx11] in givaro prevents linking to system givaro on Fedora 32

[François Bissey]

What compiler and flags have used to compile fedora 32 givaro? Can we easily 
find out?

> On 8/05/2021, at 23:31, Dima Pasechnik  wrote:
> 
> With system Givaro, one gets
> 
> [dochtml] ImportError: 
> /home/scratch2/dimpase/sage/sage/local/lib64/python3.8/site-packages/sage/matrix/matrix_modn_sparse.cpython-38-x86_64-linux-gnu.so:
>  undefined symbol: 
> _ZNK6Givaro7IntegercvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEB5cxx11Ev
> make[3]: *** [Makefile:2280: doc-html] Error 1
> 
> which demangled says
> 
> $ c++filt 
> _ZNK6Givaro7IntegercvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEB5cxx11Ev
> Givaro::Integer::operator std::__cxx11::basic_string std::char_traits, std::allocator >[abi:cxx11]() const
> 
> The system library has Givaro::Integer::operator 
> std::__cxx11::basic_string, std::allocator 
> >() const
> 
> (no of that weird [abi:cxx11] qualifier)
> 
> Any ideas how to fix this? (besides not using system Givaro) ?
> 
> Dima
> 
> -- 
> 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/b187faf3-50c4-42c4-ae37-77c5a3902bbcn%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/A5C915F7-EEC2-4B1B-835A-AFB1251E8712%40gmail.com.

[sage-devel] lcalc upstream

[François Bissey]

Hi all,

Do we have a fork and repo for lcalc to add our changes?
Some lcalc headers are currently preventing sage to compile with gcc-11
and rather than just adding some more patch to lcalc I was wondering
if we had made headways in using a forked repo for it since its upstream
development is pretty much abandoned.

Cheers,
François

-- 
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/70E3C847-227A-4D36-B88C-A2EAB94D5455%40gmail.com.

Re: [sage-devel] multi-arch Linux setup breaks doctests

[François Bissey]

Mainly https://trac.sagemath.org/ticket/31578 but really
https://github.com/sagemath/sage/blob/develop/src/sage/misc/cython.py#L56
had the potential to leak that kind of stuff forever.

> On 16/04/2021, at 21:58, Dima Pasechnik  wrote:
> 
> Since a while I see on Gentoo (with the profile
> "default/linux/amd64/17.1/desktop") many doctest errors of the kind
> 
> File "src/sage/misc/sageinspect.py", line 2251, in
> sage.misc.sageinspect.sage_getsourcelines
> Failed example:
>cython('''cpdef test_funct(x,y): return''')
> Expected nothing
> Got:
>
> /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.1/../../../../x86_64-pc-linux-gnu/bin/ld:
> skipping incompatible ///usr/lib/libm.so when searching for -lm
>
> /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.1/../../../../x86_64-pc-linux-gnu/bin/ld:
> skipping incompatible ///usr/lib/libm.a when searching for -lm
>
> /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.1/../../../../x86_64-pc-linux-gnu/bin/ld:
> skipping incompatible ///usr/lib/libpthread.so when searching for
> -lpthread
>
> /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.1/../../../../x86_64-pc-linux-gnu/bin/ld:
> skipping incompatible ///usr/lib/libpthread.a when searching for
> -lpthread
>
> /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.1/../../../../x86_64-pc-linux-gnu/bin/ld:
> skipping incompatible ///usr/lib/libc.so when searching for -lc
>
> /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.1/../../../../x86_64-pc-linux-gnu/bin/ld:
> skipping incompatible ///usr/lib/libc.a when searching for -lc
> 
> all these incompatible libs are 32-bit libs (on a 64-bit system). Is
> it a Sage (cython?)  bug/feature, or is there something else that can
> be done, short of removing all the traces of 32-bit libs from the box?
> 
> Thanks
> Dima
> 
> -- 
> 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/CAAWYfq2p3J8G3Ss39G45QkhKtnO37tav7EBmkEGXf%3DkD2LaGhA%40mail.gmail.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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/449998CE-909B-4476-84A4-C32BDAB50CEE%40gmail.com.

Re: [sage-devel] Status of modularization and packaging in Sage 9.3.beta9

[François Bissey]

> On 14/04/2021, at 16:52, Matthias Koeppe  wrote:
> 
> On Tuesday, April 13, 2021 at 9:45:19 PM UTC-7 François Bissey wrote:
> 
> I guess right now I am just after sagemath-doc-src as defined on 
> https://trac.sagemath.org/ticket/29868 
> although I am not excluding using sagemath-doc-html and sagemath-doc-pdf once 
> they become available, 
> especially for stable releases. 
> But right now I am still doing stuff by source building. 
> 
> Also, I was expecting sagemath-standard to be a sdist for sagelib.
> 
> No, for 9.3 please don't consider release tarballs on PyPI the project 
> upstream.
> What I put on PyPI is experimental for Sage 9.3 (the READMEs on PyPI note 
> this) and uses a few additional tickets which don't look like they'll make it 
> into the 9.3 release. See https://trac.sagemath.org/ticket/29705 for more 
> information.
>  
> I noticed a few differences, 
> most notably the use of a file called `sage_setup/setenv.py`. I cannot find 
> it anywhere else but 
> that pypi tarball. Is it something that disappeared in 9.3rc3 or something 
> that lives somewhere else? 
> 
> 
> See above; this one is from ticket https://trac.sagemath.org/ticket/31338 
> (needs review).
> 

Just to be clear, I am not going to release a sage-on-gentoo 9.3 out of those.
I am playing around to see what it will looks like. I like planning ahead and
frankly, with some of the stuff that has been going on around me, that’s 
literally
a way to relax.
I might want to give #31338 some distro love because there are reasons why that 
file
was suddenly on my radar. Bonus point if you figure out why before I explain it 
:)

François

-- 
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/BA418278-95C1-432E-9B73-76B3C96E1E39%40gmail.com.

Re: [sage-devel] Status of modularization and packaging in Sage 9.3.beta9

[François Bissey]

> On 14/04/2021, at 16:26, Matthias Koeppe  wrote:
> 
> On Tuesday, April 13, 2021 at 6:28:06 PM UTC-7 François Bissey wrote:
> I am looking at moving to the modular setup for sage-on-gentoo during the 9.4 
> cycle. [...]
> I now have some idea on how to build the documentation in sage-on-gentoo. But 
> the doc 
> folder is not distributed in sage math-standard. Could we have at least a 
> tarball for 
> the doc sources currently sitting under “src/doc”?
> 
> Yes, see ticket https://trac.sagemath.org/ticket/29868, which defines Python 
> distributions for the documentation.
> 

I guess right now I am just after sagemath-doc-src as defined on 
https://trac.sagemath.org/ticket/29868
although I am not excluding using sagemath-doc-html and sagemath-doc-pdf once 
they become available,
especially for stable releases. 
But right now I am still doing stuff by source building.

Also, I was expecting sagemath-standard to be a sdist for sagelib. I noticed a 
few differences,
most notably the use of a file called `sage_setup/setenv.py`. I cannot find it 
anywhere else but
that pypi tarball. Is it something that disappeared in 9.3rc3 or something that 
lives somewhere else?

François 


-- 
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/A0C6B1B8-8C5E-4B44-BB76-34D64B89896E%40gmail.com.

Re: [sage-devel] Status of modularization and packaging in Sage 9.3.beta9

[François Bissey]

I am looking at moving to the modular setup for sage-on-gentoo during the 9.4 
cycle.
I am already experimenting and feeling stuff out.
I have already expressed concerns once about building documentation. 
I now have some idea on how to build the documentation in sage-on-gentoo. But 
the doc 
folder is not distributed in sage math-standard. Could we have at least a 
tarball for 
the doc sources currently sitting under “src/doc”? 

François

> On 15/03/2021, at 13:44, Matthias Koeppe  wrote:
> 
> A quick overview of the status of the modularization effort of Meta-ticket 
> #29705 in Sage 9.3.beta9.
> 
> A source tarball of the Sage distribution (or a worktree of the Sage git 
> repository after running the ./bootstrap script) contains several 
> self-contained source trees of Python distribution packages in 
> build/pkgs/*/src/, which can be packaged, built and installed by standard 
> Python procedures:
> 
>   • setup.py sdist builds a source distribution (it is invoked by the 
> convenience script build/pkgs/*/spkg-src), which can afterwards be installed 
> using pip.
> 
>   • setup.py install installs the package directly (this is legacy use of 
> setuptools and is not recommended).
> 
>   • setup.py bdist_wheel builds a wheel, which can afterwards be 
> installed using pip.
> 
>   • Note, however, that pip install . does not work. In order to keep the 
> monolithic structure of the SAGE_ROOT/src tree unchanged (for the convenience 
> of Sage developers), the source trees of the Python distribution packages 
> make use of symlinks. These symlinks are not compatible with pip install .. 
> However, setup.py sdist follows the symlinks - the resulting source 
> distribution contains ordinary files only and is therefore pip-installable.
> 
> The following Python distribution packages exist in Sage 9.3:
> 
>   • The Sage library is built from build/pkgs/sagelib/src. Since 
> 9.3.beta8, the resulting source distribution sagemath-standard is available 
> on PyPI.
> 
>   • build/pkgs/sage_docbuild/src contains a distribution that provides 
> the Python package sage_docbuild, moved from sage_setup.docbuild in #30476. 
> Since 9.3.beta9, the resulting source distribution sage-docbuild is available 
> on PyPI.
> 
>   • build/pkgs/sage_sws2rst/src contains the source of 
> https://pypi.org/project/sage-sws2rst/
> 
>   • build/pkgs/sage_conf/src (after running the top-level configure 
> script) contains the source of the Sage configuration package, which provides:
> 
>   • a single Python module, sage_conf, providing configuration 
> information to the SageMath library at the time of its installation and at 
> its runtime
> 
>   • a console script sage-config, for querying the variables of 
> sage_conf from the shell
> 
>   • the sourcable shell script sage-env-config, providing 
> additional configuration information in the form of environment variables.
> 
> I hope that we can still merge the following tickets in Sage 9.3, which are 
> waiting for review:
> 
>   • #30913: Generate pyproject.toml and setup.cfg [install_requires], 
> requirements.txt, Pipfile, and src/Pipfile
>   • #29039: pip-installable version of package sage_conf - installs 
> non-Python bits of the Sage distribution in ~/.sage/
>   • #30383: Add configure --disable-notebook; show descriptions of 
> optional packages in configure --help
> (see https://trac.sagemath.org/ticket/29705 for more details)
> 
> 
> 
> 
> -- 
> 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/f4672d2d-ae7d-4b94-8697-c945ad961ac8n%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/D4B3B3BF-A33A-4184-A6F7-261095411F13%40gmail.com.

Re: [sage-devel] Doctest memory limit

[François Bissey]

Running the doctests plong style just regularly fails for him on some machines 
with
memory errors. Re-running the tests with higher limits usually works. But the 
default
are obviously too low on some of his machines. 

> On 24/03/2021, at 13:16, Volker Braun  wrote:
> 
> I don't understand what the big pain point is, if Steve doesn't like the 
> limit it he can just pick a different value no?

-- 
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/3F60C80B-EF55-4669-9DF4-AD16E9E6A8C0%40gmail.com.

Re: [sage-devel] Doctest memory limit

[François Bissey]

It has been a pain for Steve Trogdon in sage-on-gentoo on an ongoing basis
ever since it was included. I have somehow been blessed with enough RAM on
all my dev machines. You sum and articulate my position on the matter quite 
nicely and even with additional bullet points (the last three are really the 
ones that have been on the back of my mind for awhile).

You could say I am biased but I wouldn’t be sorry to say goodbye to the thing.

François

> On 23/03/2021, at 13:21, Michael Orlitzky  wrote:
> 
> Is anyone very much in love with the --memlimit (default: 3300MB)
> option to the sage -t command?
> 
> Once again it has completely broken testing on some systems. We could
> try to guess a new, higher limit... or just admit that maybe it's not a
> great idea after all and delete the thing. The latter is what I'm about
> to propose on https://trac.sagemath.org/ticket/31395
> 
> A few points:
> 
>  * The failure of the default limit has been and will always be a 
>recurring problem as sage requires more and more memory. Every
>time we hit it, a bunch of machines are broken until the limit
>can be raised in the "develop" branch.
> 
>  * The default memory limit exists for precisely one doctest (which 
>I've refactored to still be tested, modulo the next bullet point).
> 
>  * Testing out-of-memory conditions doesn't test what you'd expect, 
>since if you _actually_ run out of memory, all hell breaks loose
>on the system at the same time as your graceful error handling 
>kicks in.
> 
>  * A global limit is likely incorrect, as would be revealed if there 
>were more than one doctest using it. Each test needs the limit to
>be low enough to trigger a failure, but not low enough to crash
>the rest of sage. Both of these numbers are test- and system-
>dependent.
> 
>  * Reimplementing "ulimit -v" in a mathematics suite is a waste of
>development resources.
> 
> I'd rather just delete it and generalize the one existing doctest with
> something like a "with memlimit(...)" context manager in the unlikely
> event that we ever have another test for OOM behavior.
> 
> 
> -- 
> 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/fb887a37abdddeb77e05d433983b3d1ae8dca149.camel%40orlitzky.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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/908A7748-9150-4521-AFAE-C6148C2BB287%40gmail.com.

Re: [sage-devel] Linking libraries with spkg-install.in

[François Bissey]

> On 19/03/2021, at 23:05, 'jonatha...@googlemail.com' via sage-devel 
>  wrote:
> 
> We configure libaries with e.g. `--with-zlib="$SAGE_LOCAL"` unconditionally. 
> Why would this succeed, if we use the systems `zlib`?
> 

It depends a bit on whether you use a properly written configure script or not.
Autotools tests and finds things by trying to compile things. If there is no
lib in SAGE_LOCAL it will not prevent a compilation against a system zlib to 
fail.
gcc -o test -I$SAGE_LOCAL/include -L$SAGE_LOCAL/lib test.c -lz
will look first in the SAGE_LOCAL locations but will still use the standard 
location
if nothing is found in the custom ones.

Where it will fail, is with custom scripts that work by trying to find a file 
explicitly.
Like checking whether $SAGE_LOCAL/lib/libz.so exists. Those are bad tests in 
the first 
place.

François

-- 
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/2BAF2668-6CD0-4849-8293-F3D2523DDE8A%40gmail.com.

Re: [sage-devel] pointy python question related to sage

[François Bissey]

You have the gist of it. There are various environment variables that can 
suppress or enable
the use of sage as a back for multi-precision numbers. Historically that 
sometime caused trouble 
in sympy as well.

> On 19/03/2021, at 05:28, Nils Bruin  wrote:
> 
> Am I understanding correctly that "import mpmath" should behave differently 
> when called in a sage context rather than in a straight python context, and 
> that (in case of a system python) it may be possible that within the same 
> python installation both behaviours are desirable on occasion?
> 
> From what I understand, python packages upon import may sometime probe 
> availability of certain other packages (by trying to import them) and may 
> fall back on other options if they are not. This allows certain "optional 
> dependencies".
> 
> In this case, it doesn't sound like an optional dependencies, but really as 
> two different modes for mpmath. It seems to me one should select between 
> those modes explicitly; whether through an environment variable or some flag 
> inside python.
> 

Indeed and from the mpmath dev point of view, they want the default mode to
be without sage, unless explicitly enabled. But at the moment the only way 
forward
I have as a sage-on-gentoo packager is to reverse those default once sage is 
installed.

If you are only ever using sage from the sage executable, you could set it in 
sage-env
so it would be set when you start sage. But in sage-on-distro and increasingly 
in mainstream
sage, a good amount of work has been put in the design of env.py so that you 
can import sage 
from python directly. In which case you bypass the sage executable.
Apart from installation (work in progress), sage is pretty much a regular 
python package these days.

> Design-wise this causes another problem: if a python package relies on mpmath 
> in non-sage mode, then you can now not use it inside sage. That's an 
> unfortunate incompatibility and something one might generally want to avoid.

While there could be numerical noise between backends, I would say that 
this kind of problems means you are using something that shouldn’t be 
exposed to the user, a private API.

This is probably something bad sage does as well. When mpmath is in non
sage mode and called from sage you get all sorts of failures. For example:

sage -t --long --random-seed=0 
/usr/lib/python3.9/site-packages/sage/calculus/calculus.py
**
File "/usr/lib/python3.9/site-packages/sage/calculus/calculus.py", line 372, in 
sage.calculus.calculus
Failed example:
[f[0].n() for f in _.coefficients()]  # numerical coefficients to make 
comparison easier; Maple 12 gives same answer
Exception raised:
Traceback (most recent call last):
  File "sage/symbolic/expression.pyx", line 6186, in 
sage.symbolic.expression.Expression.numerical_approx 
(/dev/shm/portage/sci-mathematics/sage-/work/sage-/src-python3_9/build/cythonized/sage/symbolic/expression.cpp:37043)
x = x._convert(kwds)
  File "sage/symbolic/expression.pyx", line 1495, in 
sage.symbolic.expression.Expression._convert 
(/dev/shm/portage/sci-mathematics/sage-/work/sage-/src-python3_9/build/cythonized/sage/symbolic/expression.cpp:10451)
cdef GEx res = self._gobj.evalf(0, kwds)
  File "sage/libs/pynac/pynac.pyx", line 2139, in 
sage.libs.pynac.pynac.py_psi2 
(/dev/shm/portage/sci-mathematics/sage-/work/sage-/src-python3_9/build/cythonized/sage/libs/pynac/pynac.cpp:25306)
return mpmath_utils.call(mpmath.psi, n, x, prec=prec)
  File "sage/libs/mpmath/utils.pyx", line 439, in 
sage.libs.mpmath.utils.call 
(/dev/shm/portage/sci-mathematics/sage-/work/sage-/src-python3_9/build/cythonized/sage/libs/mpmath/utils.c:7129)
y = mpmath_to_sage(y, prec)
  File "sage/libs/mpmath/utils.pyx", line 272, in 
sage.libs.mpmath.utils.mpmath_to_sage 
(/dev/shm/portage/sci-mathematics/sage-/work/sage-/src-python3_9/build/cythonized/sage/libs/mpmath/utils.c:5518)
mpfr_from_mpfval(y.value, x._mpf_)
  File "sage/libs/mpmath/utils.pyx", line 167, in 
sage.libs.mpmath.utils.mpfr_from_mpfval 
(/dev/shm/portage/sci-mathematics/sage-/work/sage-/src-python3_9/build/cythonized/sage/libs/mpmath/utils.c:4702)
sign, man, exp, bc = x
TypeError: Cannot convert mpz to sage.rings.integer.Integer

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.9/site-packages/sage/doctest/forker.py", line 714, 
in _run
self.compile_and_execute(example, compiler, test.globs)
  File "/usr/lib/python3.9/site-packages/sage/doctest/forker.py", line 
1133, in compile_and_execute
exec(compiled, globs)
  File "", line 1, in 
[f[Integer(0)].n() for f in _.coefficients()]  # numerical coefficients 
to make comparison easier; Maple 12 gives same answer
  File "", 

[sage-devel] pointy python question related to sage

[François Bissey]

Hi all,

I was wondering if there was a way to figure if a module from one
package is imported from another one and which one at that.

This is quite relevant to sage-on-distros. mpmath-1.2.0+ tries
to figure out if it is called from sage by detecting if SAGE_ROOT
is defined. Assuming that if it is this is a sage install.
Some reasoning at 
https://github.com/fredrik-johansson/mpmath/pull/466
the reasoning in question disregarded the fact that a sage-on-distro
package would also likely use a system mpmath.

But mpmath developers don’t want to just use sage if it is installed.
Only if it is explicitly required and available or because they
mpmath is called from sage.

MPMATH_SAGE could be set in the sage executable or sage-env but
that would cover the case where you import sage directly from 
python. Something that has been doable on sage-on-(some)-distros
for years and is quite doable in villa sage these days.

So I am wondering if there is a python way to say to mpmath, you
have been imported from sage.

Cheers,
François

-- 
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/D4CBBAD2-E1D1-4A10-B757-111008A02B92%40gmail.com.

Re: [sage-devel] distro packaging, docbuilding and modularisation

[François Bissey]

> On 12/03/2021, at 12:14, Matthias Koeppe  wrote:
> 
> On Thursday, March 11, 2021 at 3:07:41 PM UTC-8 François Bissey wrote:
> 
> > On 12/03/2021, at 11:48, Matthias Koeppe  wrote: 
> When are we going to start seeing separate sdist tarballs? That’s really the 
> point at which 
> I am going to switch the way I do things.
> 
> this one? https://pypi.org/project/sagemath-standard/#files

Even for betas? I was thinking there would only be some for proper releases.
Well, I should get ready to use that stuff directly rather than the sage
git tarball with stuff that I do not use and that requires special settings 
to figure out where the sources are located.
9.3 may very well be my last “classic" release of sage. Although I may still
consider to have a special branch to do the work I currently do directly 
on git for a while.

-- 
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/AC3A0898-4C20-4C92-99DD-981DEA6BFE87%40gmail.com.

Re: [sage-devel] distro packaging, docbuilding and modularisation

[François Bissey]

> On 12/03/2021, at 11:48, Matthias Koeppe  wrote:
> 
> No, there's nothing wrong with it; this is the normal way to use the 
> repository now and in the planned future. 
> After running ./bootstrap, the source tree contains several self-contained 
> Python distribution package source trees in build/pkgs/*/src/, which can be 
> built and installed normally (setup.py install, setup.py bdist_wheel, etc.). 
> Right now * is "sagelib", "sage_docbuild", and "sage_sws2rst". Modularization 
> will add more.
> https://trac.sagemath.org/ticket/29868 will add "sagemath_doc_html" -- your 
> custom script to build the documentation will reduce to running "setup.py 
> install" for this package.
> 

When are we going to start seeing separate sdist tarballs? That’s really the 
point at which
I am going to switch the way I do things.

-- 
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/24348B38-91EF-42DA-B37B-847F9F096E53%40gmail.com.

Re: [sage-devel] distro packaging, docbuilding and modularisation

[François Bissey]

> On 12/03/2021, at 11:20, Matthias Koeppe  wrote:
> 
> Well, autotools does not even have a mechanism to advertise 
> dependencies/requirements -- other than "configure" exiting with an error if 
> they are not satisfied. You as a downstream package maintainer declare and 
> update the requirements based on (in the best case) package documentation.
> 

Yup, it is just a build system. Languages that come with package management 
are a relatively new in a way [OK, R had one for a long time, I am sure there
are others]. 
It took some time for it to mature to the present state in python.

-- 
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/781C118E-CB95-4DA1-BCFA-DC02D046B1BC%40gmail.com.

Re: [sage-devel] distro packaging, docbuilding and modularisation

[François Bissey]

> On 12/03/2021, at 11:20, Matthias Koeppe  wrote:
> 
> And then -- of course likely not relevant for gentoo -- there is also the 
> distinction between source and binary distributions (wheels): For the package 
> itself, many users have a good reason to build it from source; but for a 
> separate documentation package, most users do not really benefit from 
> building it from source - they can as well install a prebuilt wheel providing 
> the documentation. These users will then not have a need to install Sphinx at 
> all.

I guess it is my fault for doing CI, including doc, straight from git.
Some may say I am abusing the package manager in doing so. But someone
really put some thoughts in making the tools available for it. If there wasn’t
a couple more kinks here and there, I could test branches attached to tickets
directly from it. 
I’d really like to continue to do stuff the way I have been doing them. 
But if they have to go extinct, that’ll just be that.

-- 
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/17F61FCF-B049-4D49-BF42-2FC463FB5796%40gmail.com.

Re: [sage-devel] distro packaging, docbuilding and modularisation

[François Bissey]

> On 12/03/2021, at 09:46, Matthias Koeppe  wrote:
> 
> On Wednesday, March 10, 2021 at 8:18:11 PM UTC-8 Nathan Dunfield wrote:
> On Wednesday, March 10, 2021 at 4:50:41 AM UTC-6 Dima wrote:
> numpy does this:
> https://numpy.org/devdocs/docs/howto_build_docs.html
> 
> you can only build numpy docs after numpy is installed.
> 
> Of course, with numpy "installed" doesn't necessarily mean installed in the 
> main site-packages, you can use a virtualenv.  Then you delete the virtualenv 
> once the docs are built and install the module and the docs for real.  
> 
> Just a quick comment that you get this type of build isolation for free if 
> you make the documentation a separate distribution according to PEP 517 
> (pyproject.toml), for which you declare the package as a build-system 
> requirement.
> 

I have been wondering for a while why you want to have those kinds of 
requirements.
In the autotools world there is no issues with building documentation as part 
of the
building process even if, potentially like sage, you want some content to be 
dynamically
generated by executing the just built package.

And that’s when it hits me. In a lot of python packages, building the 
documentation,
when it is available, a different build system is used than when you where
building the package itself. 
In a typical case, you build with distutils/setuptools and then invoke make to 
start
sphinx to build the doc.

The python build systems in wide use have no hooks or provision to latch on to 
stuff 
you use to build the documentation. If they do they are not in wide use, or may 
be 
too primitive.

In that context, since you often use a completely different way of building 
stuff,
those PEPs literally mandate a separate package. The only alternative is to 
include
provision for documentation building in stuff like setuptools. I don’t see that 
happening
anytime soon.

-- 
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/0890DCDD-47C4-42ED-956E-961C94817842%40gmail.com.

Re: [sage-devel] distro packaging, docbuilding and modularisation

[François Bissey]

> On 12/03/2021, at 09:41, Matthias Koeppe  wrote:
> 
> On Thursday, March 11, 2021 at 11:36:18 AM UTC-8 Antonio Rojas wrote:
> Here is my current PKGBUILD (after some cleanup I did today) 
> https://github.com/archlinux/svntogit-community/blob/packages/sagemath-doc/trunk/PKGBUILD
> I'm building the docs in a separate package for practical purposes (sage 
> requires frequent rebuilds for soname bumps in dependencies, and I don't want 
> to have to build the docs every time) [...]
> 
> Yes, this is an important insight. Sage documentation and Sage library have 
> sharply different dependencies - both at build time and at installation time. 
> The design in https://trac.sagemath.org/ticket/29868 models the Python 
> package dependencies (PEP 518 build system requirements, and install 
> requires) to reflect this. 
> 

For the record, I used to have a separate package for documentation years ago
and I walked away from that. Source distributions have different set of 
parameters
to play with. 

That being said, building the sage documentation is a relatively heavy task so 
for 
releases I build a documentation set that can be used instead of building it 
from 
scratch. That set doesn’t change even if I revise the package one way or 
another 
(unless I fix a documentation specific issue). 

For beta and rc release, my expectation is that if you want documentation 
you’ll have
to build it. If you follow beta and rc I am expecting you want the “fast” paced 
changes
and to have the capacity for a doc build if you wish it.

I personally do CI from Volker merge tree with my install, so I build and test 
as
things gets merged, that includes the documentation. If doing the documentation
gets too difficult to put in the framework I use, I will just ditch it in 
favour to
whatever version is last available upstream. No more testing of that from me.

-- 
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/789E015D-044D-478B-B67B-8BCD7880E7E8%40gmail.com.

Re: [sage-devel] distro packaging, docbuilding and modularisation

[François Bissey]

> On 11/03/2021, at 05:03, Matthias Koeppe  wrote:
> 
> On Wednesday, March 10, 2021 at 1:21:07 AM UTC-8 François Bissey wrote:
> [...] building the documentation [...] 
> 
> In https://trac.sagemath.org/ticket/29868 I sketch a design that is in line 
> with modern Python packaging, in particular build isolation. I welcome 
> discussions based on this.

build isolation is nice. If python packaging says that what numpy does 
and sage is about to do is right, they are completely diverging from
traditional packaging. May be packagers have been wrong all along.

In a way, it mimics the way commercial closed packages tend to behave and
be distributed. And I don’t like that imitation one bit. It rubs me the
wrong way. Reading myself, I hope I am not turning into a “Richard Stallman”
but I am certainly opinionated and not afraid of it.

François

-- 
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/AAEDB4E9-745F-4290-85F4-F27059475138%40gmail.com.

Re: [sage-devel] distro packaging, docbuilding and modularisation

[François Bissey]

> On 11/03/2021, at 01:10, Antonio Rojas  wrote:
> 
> El miércoles, 10 de marzo de 2021 a las 10:21:07 UTC+1, François Bissey 
> escribió:
> Instead of trying to fix the problem that you should be building the 
> documentation 
> before installing, the push to modularisation is currently used to enshrine 
> the 
> current situation. #30010 actually separate the bits needed to build the sage 
> documentation in a completely separate package. 
> So the situation is now: 
> * install package A 
> * install package B 
> * make a package C that takes B and applies it to the install of A and 
> install 
> the documentation of A (not C). 
> 
> 
> Hi,
>  As long as everything is still shipped in the Sage source tarball, isn't it 
> just a matter of changing a path in the build script? I've always run the doc 
> build directly from the Sage source, without installing anything, and I hope 
> to be able to keep doing it that way (after a quick test, it still seems to 
> be possible after #30010). Of course, if the long term plan is to split this 
> to a separate git repo, then I completely share your concerns. 
> 

I’d like to talk to you on another channel, I have to do a small
patch currently. It may reflect different packaging strategy or
something I could improve.

François

-- 
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/C2A6536C-BCA9-4B7E-82C8-0D427886BF19%40gmail.com.

Re: [sage-devel] distro packaging, docbuilding and modularisation

[François Bissey]

> On 10/03/2021, at 23:50, Dima Pasechnik  wrote:
> 
> On Wed, 10 Mar 2021, 09:21 François Bissey,  wrote:
> So the situation is now:
> * install package A
> * install package B
> * make a package C that takes B and applies it to the install of A and install
> the documentation of A (not C).
> 
> Can anyone point me to some other system that do that? Does anyone else 
> thinks 
> that’s a bit insane?
> 
> numpy does this:
> https://numpy.org/devdocs/docs/howto_build_docs.html
> 
> you can only build numpy docs after numpy is installed.
> 

And Gentoo doesn’t even try to build the doc we use their provided tarball.

As far as I see it, the way sage sage is going I won’t build or test the 
documentation
anymore and rely on you producing tarballs. Which means there won’t be version 
bump
of sage in Gentoo until those exists when that happens.

François

-- 
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/7BC141F4-4A95-4624-B538-8C48FEC3F1D7%40gmail.com.

[sage-devel] distro packaging, docbuilding and modularisation

[François Bissey]

Hi all,

So today I will be talking about subject that I in sage-on-gentoo have
brushed under the carpet for years focusing on helping to be able to
use more and more components of the system and ultimately get “sagelib”
to be one such component.

Sagemath as a meta distribution of stuff has bad habits in regards to
treating “sagelib” as a regular package. In short it doesn’t.

A normal software package usually should only contains it own sources,
vendoring as it is called should be kept at a minimum and some other 
best practise are that 
* the package can be tested after being built and before being installed
* the package documentation be built usually after the package itself,
but before it is installed and the documentation should be installed 
at the same time as the rest of the package.

Some project offer pre-build documentation, as part of the package if
it is small, or downloadable tarballs if it is large. It is also
the way to go for particularly difficult to build documentation.
I’d say Sagemath will eventually go that way.

So, we have made progress on vendoring, sage-on-gentoo has been building
Sagelib and the documentation as a regular well behaved package for years 
and I have only pestered about the testing. Modularisation may force some
things about the testing and offer solutions to an unmentioned problem
so far, optional dependencies.

But my situation about being able to build the documentation is under
threat and is hack-ish in any case.

So how are we building, installing and testing the elements of “vanilla" sage
at the moment:
* sagelib is built and installed
* using the sagelib install the documentation is built. It is not supposed to be
possible to build the doc without installing sage first, which is why 
sage-on-gentoo’s
ability is really a hack
* testing is done on the installed elements, that includes running tests inside 
the documentation

Instead of trying to fix the problem that you should be building the 
documentation
before installing, the push to modularisation is currently used to enshrine the
current situation. #30010 actually separate the bits needed to build the sage
documentation in a completely separate package.
So the situation is now:
* install package A
* install package B
* make a package C that takes B and applies it to the install of A and install
the documentation of A (not C).

Can anyone point me to some other system that do that? Does anyone else thinks 
that’s a bit insane?

#30010 is not all bad. Doc building elements have been buried inside sage_setup
for a while and that wasn’t a good thing. sage_setup is mostly useless at
runtime and shouldn’t really be installed unless some downstream packages can
make use of it. But the doc building elements are already used by downstream 
packages (p_cohomology_group does), so installing them has some value.

My own idea of modularisation would be that each package should be able to build
its own documentation and be testable on its own, before install. Not to split
the whole documentation as a separate package.

I want to repeat #30010 is not without value. Having a helper package to build
the documentation is not a bad idea in itself so long as it applies in the 
following 
order:
* install B (the doc building helper)
* build A, build A’s documentation using B
* install A and its documentation
No C please.

If you read this far, thank you. That’s long enough for such a rant.

François


-- 
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/BE94013F-0363-4E78-94AD-93390E8669EA%40gmail.com.

Re: [sage-devel] Gentoo: Unable to configure vanilla Sage with system fplll

[François Bissey]

And we already fixed it in https://trac.sagemath.org/ticket/31127
which should be in the next beta.

> On 12/01/2021, at 8:46 AM, Dima Pasechnik  wrote:
> 
> it's a bug introduced in
> 26032b18f9b (Martin Albrecht  2020-12-15 12:12:14 + 11)
>   [fplll == 5.4]
> 
> it should be '=', not '==' there
> 
> On Mon, Jan 11, 2021 at 7:22 PM Steven Trogdon  
> wrote:
>> 
>> On gentoo, after
>> 
>> make fplll-clean
>> ./configure --with-system-fplll=yes
>> 
>> from config.log there is
>> 
>> configure:39046: result: fplll-5.4.0: no 
>> suitable system package; will be installed as an SPKG
>> 
>> However, I have system fplll-5.4.0 installed
>> 
>> [I] sci-libs/fplll
>> Available versions:  ~4.0.4 5.3.2(0/6) (~)5.3.3(0/6) (~)5.4.0(0/7) {qd 
>> static-libs}
>> Installed versions:  5.4.0(0/7)(12:27:23 PM 12/22/2020)(-qd -static-libs)
>> Homepage:https://github.com/fplll/fplll
>> Description: Implementations of the floating-point LLL reduction 
>> algorithm
>> 
>> Is this the expected behavior?
>> 
>> --
>> 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/beb8dff9-7208-4bf6-9824-e962aaadef47n%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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/CAAWYfq3ZVU0WaGvkhpCqF60AQA0eezxnMeQc1xt%3Dw5xP8Z-3oQ%40mail.gmail.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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/7F247636-F35D-4976-8F6D-7A20CB454915%40gmail.com.

[sage-devel] Away until the 4th of January

[François Bissey]

Hi all,

This is the time of the year where I go for a few days of internet detox.
No reviews or contributions from me until next Monday.

Cheers,
François

-- 
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/CE3354FB-C11F-4D89-B4F8-C6E836A1187C%40gmail.com.

Re: [sage-devel] Making the package jmol optional

[François Bissey]

> On 7/12/2020, at 10:25 PM, Antonio Rojas  wrote:
> 
> El lunes, 7 de diciembre de 2020 a las 6:11:31 UTC+1, Matthias Koeppe 
> escribió:
> In https://trac.sagemath.org/ticket/30315 I propose to make jmol optional. To 
> my understanding it has been replaced by generally better options such as 
> threejs and jsmol. But it's possible that I'm missing something.
> 
> The Javascript version of it, previously installed as part of jmol, is 
> switched on this ticket to come from the pip-installable package 
> jupyter-jsmol.
> 
> Is there any reason for not making jsmol optional too? Isn't three.js the 
> default renderer these days?
>  

three.js still cannot be used to build the doc as far as understand.

-- 
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/3BE950C9-0F6F-41EE-AC64-2B636DA04F0D%40gmail.com.

Re: [sage-devel] Sage Days 111 - Global Virtual Sage Modularization and Packaging Summit - Dec 8-11

[François Bissey]

18:00 UTC is 7:00am the next day for me. What with dropping kids to school, I 
probably won’t show up
until 20:00 UTC.

> On 6/12/2020, at 2:47 PM, Matthias Koeppe  wrote:
> 
> A preliminary schedule is now posted.
> 
> 
> On Sunday, November 22, 2020 at 11:41:01 AM UTC-8 Matthias Koeppe wrote:
> Sage Days 111 (Global Virtual Sage Modularization and Packaging Summit)
> will be held Dec 8-11, with a core synchronous event on the first day, 
> followed by asynchronous coding sprints and scheduled status reports on the 
> remaining days.
> 
> More information: https://wiki.sagemath.org/days111
> 
> 
> 
> -- 
> 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/03687ac1-f40a-4eb7-8e26-a575809c80ben%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/475056A2-A4BC-40A0-8BB6-F0C8A51BC5F2%40gmail.com.

Re: [sage-devel] Apple M1 Chip

[François Bissey]

Also suitesparse. 
Of course one of thing is actually blas/lapack (openblas)- but
with any luck we can use the accelerate framework from OS X.
I haven’t heard it is not available on macs with M1 chips so I am 
assuming it is present.

> On 25/11/2020, at 3:46 PM, kcrisman  wrote:
> 
> 
> 
> IMHO it's known to work with numpy, scipy, and R. 
> 
> 
> That's pretty much all we need fortran for, right?   Good news.   Still, the 
> toolchain will be more annoying than on current Mac then. 
> 
> -- 
> 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/fbdb111c-79a0-4319-9acb-b65e109a55d8n%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/5DCFE27C-5585-469B-A634-BD75166D9EA2%40gmail.com.

Re: [sage-devel] Apple M1 Chip

[François Bissey]

That would be a new fortran compiler. I did builds in the past with 
the intel fortran compiler and the PG compiler but not NAG.
You’ll be in totally uncharted territory.

Fraçois

> On 25/11/2020, at 5:36 AM, Dima Pasechnik  wrote:
> 
> Anyhow, there is
> https://www.nag.com/news/first-fortran-compiler-apple-silicon-macs
> (and we have insiders in NAG, perhaps we can get these for free...)
> 
>> 
>> On Tuesday, November 24, 2020 at 10:47:42 AM UTC-5 kcrisman wrote:
>>> 
>>> Hi sage-devel,
>>> 
>>> The only references I could find to this so far are
>>> https://ask.sagemath.org/question/54220/apple-silicon-m1-chip/
>>> and
>>> https://groups.google.com/g/sage-devel/c/5yY3VmkT4kE/m/P21QdaMUBgAJ
>>> where I asked more generally about ARM.
>>> 
>>> I am likely to be assigned such a laptop in the near future, but it would 
>>> be nice not to be a total guinea pig (since I rely on having Sage for a 
>>> number of different purposes in my teaching).  Though I am willing to be a 
>>> partial guinea pig if I get the computer early enough in our semester break!
>>> 
>>> Anyway, in the intervening weeks since those posts, has anyone happened to 
>>> hear more about this (either for Sage or for dependencies like 
>>> BLAS/Numpy/MPIR)?  This will be the default for a lot of people pretty soon.
>>> 
>>> Thanks,
>>> kcrisman
>> 
>> --
>> 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/503ba9b5-637e-43cc-a448-35e196a9b643n%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/93A6A60B-D9BD-4869-AFB9-B4332245B196%40gmail.com.

Re: [sage-devel] ImportError: failed to map segment from shared object

[François Bissey]

It is a very interesting memory management problem.
Wish I could find the bottom of it.
https://github.com/cschwan/sage-on-gentoo/issues/610

> On 23/11/2020, at 10:59 PM, Dima Pasechnik  wrote:
> 
> On a Gentoo machine I got the toolchain broken in an interesting way:
> I get errors such as
> 
> ImportError: 
> local/lib/python3.7/site-packages/sage/ext/interpreters/wrapper_py.cpython-37m-x86_64-linux-gnu.so:
> failed to map segment from shared object
> 
> on many, if not all, Cython modules, even though the build completes
> and Sage starts (but about 10% or 20% of the tests fail)
> 
> Any idea what's going on?
> 
> Dima
> 
> -- 
> 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/CAAWYfq0abfMfzTfxMJ_9eBDa6aDKW_6vrcvpwxrRyWS7ZAZUXQ%40mail.gmail.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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/C52B57AE-7FDE-45DF-B58F-B5CDA8DA64ED%40gmail.com.

Re: [sage-devel] Jupyter notebook crashes with multiusers

[François Bissey]

Well it certainly wasn’t changed each time we upgraded MPL (and yes I am part
of the guilty) as it should have.

François

> On 14/11/2020, at 7:05 AM, Matthias Koeppe  wrote:
> 
> We have some suspicious code in src/bin/sage-env; perhaps this is a good 
> opportunity to review whether this should be changed.
> 
> if [ -z "$MPLCONFIGDIR" ]; then
> # We hardcode a version number in the directory name. The idea is
> # that we keep using the same version number as long as that is
> # possible. Only when some future Matplotlib version really requires
> # a new structure for the $MPLCONFIGDIR should this version
> # number be changed to the new matplotlib version.
> export MPLCONFIGDIR="$DOT_SAGE/matplotlib-1.5.1"
> fi
> 

-- 
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/352EC79C-0E39-44C5-A687-1ABA8505B9EA%40gmail.com.

Re: [sage-devel] Jupyter notebook crashes with multiusers

[François Bissey]

The top of your crash log is interesting, especially with the context you give 
it.

[I 08:54:47.064 NotebookApp] 302 GET 
/?token=9646f700a842467835ef92b578ebef632e86a326a85e828b (127.0.0.1) 1.53ms
[I 08:54:56.520 NotebookApp] Kernel started: 
d273c9d9-80cb-45a6-a336-b3562f294b26, name: sagemath

/srv/public/shared/DGI-sage/local/lib/python3.8/site-packages/cysignals/signals.cpython-38-x86_64-linux-gnu.so(+0x8bb8)[0x7faa181e6bb8]
/srv/public/shared/DGI-sage/local/lib/python3.8/site-packages/cysignals/signals.cpython-38-x86_64-linux-gnu.so(+0x8c58)[0x7faa181e6c58]
/srv/public/shared/DGI-sage/local/lib/python3.8/site-packages/cysignals/signals.cpython-38-x86_64-linux-gnu.so(+0xc89d)[0x7faa181ea89d]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12730)[0x7faa1cb3b730]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x10b)[0x7faa1c8107bb]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x121)[0x7faa1c7fb535]
/lib/x86_64-linux-gnu/libgcc_s.so.1(+0x3358)[0x7faa1a2f8358]
/srv/public/shared/DGI-sage/local/lib/python3.8/site-packages/matplotlib/ft2font.cpython-38-x86_64-linux-gnu.so(+0x7a62)[0x7fa87edd6a62]
/srv/public/shared/DGI-sage/local/lib/python3.8/site-packages/matplotlib/ft2font.cpython-38-x86_64-linux-gnu.so(_ZN7FT2FontC1ER13FT_Open_Args_l+0x22b)[0x7fa87edda23b]
/srv/public/shared/DGI-sage/local/lib/python3.8/site-packages/matplotlib/ft2font.cpython-38-x86_64-linux-gnu.so(+0xd35f)[0x7fa87eddc35f]


I’d say it is trying to open a font file to which it has no right.

François
 
> On 13/11/2020, at 9:54 PM, 'jonatha...@googlemail.com' via sage-devel 
>  wrote:
> 
> Dear all,
> 
> the jupyter notebook crashes when trying to plot unbounded polyhedra, e.g.:
> 
> P = Polyhedron(ieqs=[(0,1,0)])
> P.show()
> 
> Bounded polyhedra seem to work fine, but also plotting of the face lattice, a 
> FiniteLatticePoset, fails (even for the cube).
> 
> The crash appears to be deterministic, but only users other than the owner. 
> (I changed the permissions to 777 inbetween, this does not seem to be the 
> issue.)
> 
> This happens on a 9.2. install, but also on a 9.1beta5 install on a different 
> machine (both debian buster).
> 
> It does work for prebuilt binaries (9.2 and 9.1).
> 
> Here are the system packages picked up:  (* are those that also are picked up 
> for the 9.1beta5 with the same problem).
> 
> boost-1_66_0:using system package; SPKG will 
> not be installed
> boost_cropped-1.66.0.p0: using system package; SPKG will 
> not be installed
> *bzip2-1.0.6-20150304.p0: using system package; SPKG will 
> not be installed
> *cmake-3.18.2:using system package; SPKG will 
> not be installed
> *curl-7.62.0.p0:  using system package; SPKG will 
> not be installed
> *gcc-9.2.0:   using system package; SPKG will 
> not be installed
> gfan-0.6.2.p1:   using system package; SPKG will 
> not be installed
> *gfortran-9.2.0:  using system package; SPKG will 
> not be installed
> *git-2.11.0:  using system package; SPKG will 
> not be installed
> *gmp-6.1.2:   using system package; SPKG will 
> not be installed
> *iconv-1.15:  using system package; SPKG will 
> not be installed
> *mpfr-4.0.1.p0:   using system package; SPKG will 
> not be installed
> *mpir-3.0.0-644faf502c56f97d9accd301965fc57d6ec70868.p0:using system package; 
> SPKG will not be installed
> *ncurses-6.0.p0:  using system package; SPKG will 
> not be installed
> *ninja_build-1.8.2:   using system package; SPKG will 
> not be installed
> pandoc-none: using system package; SPKG will 
> not be installed
> *patch-2.7.5: using system package; SPKG will 
> not be installed
> *pcre-8.40.p2:using system package; SPKG will 
> not be installed
> *perl_term_readline_gnu-1.35: using system package; SPKG will 
> not be installed
> *pkgconf-0.9.7.p2:using system package; SPKG will 
> not be installed
> *readline-8.0:using system package; SPKG will 
> not be installed
> *xz-5.2.2.p0: using system package; SPKG will 
> not be installed
> *zlib-1.2.11.p0:  using system package; SPKG will 
> not be installed
> 
> Does anyone know what might be the problem?
> 
> In the section for installinging sagemath for multiusers there is no hint
> https://doc.sagemath.org/html/en/installation/source.html#id11
> 
> The full config.log and the crash report are attached.
> 
> Thank you,
> 
> Jonathan
> 
> 
> -- 
> You received 

Re: [sage-devel] Ubuntu 20.10 build of 9.3beta1 failing on fplll

[François Bissey]

libqd.a in your /usr/local/lib folder has been compiled without -fPIC and cannot
be used to build a shared library.
As stated by Dima, you shouldn’t need to install your own. If you insist on 
using
a libqd from /usr/local/lib, install one compiled with -fPIC.

François

> On 13/11/2020, at 10:40 AM, Kiran Kedlaya  wrote:
> 
> I'm trying to build Sage 9.3beta1 on my Ubuntu 20.10 laptop, and the build is 
> failing in fplll-5.3.3. The relevant lines seem to be
> 
> [fplll-5.3.3] /usr/bin/ld: /usr/local/lib/libqd.a(dd_const.o): warning: 
> relocation against `_ZN7dd_real4_pi4E' in read-only section `.text.startup'
> [fplll-5.3.3] /usr/bin/ld: /usr/local/lib/libqd.a(dd_real.o): relocation 
> R_X86_64_PC32 against symbol `_ZSt4cerr@@GLIBCXX_3.4' can not be used when 
> making a shared object; recompile with -fPIC
> 
> I can include a more detailed log if needed, but let's see if this is already 
> enough to generate some suggestions...
> 
> Kiran
> 
> -- 
> 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/37a140b4-67a9-4f0a-ba3b-28259f134ca1n%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/E0C63370-B242-4F55-9FBB-847982279A8C%40gmail.com.

Re: [sage-devel] Error installing package gap_packages-4.10.2.p1

[François Bissey]

That’s a gcc-10 porting issue. I thought the fix from upstream had been applied.
Someone more familiar with the ticket should comment.

> On 28/10/2020, at 12:22 PM, 'Peter Mueller' via sage-devel 
>  wrote:
> 
> On a Lenovo ThinkPad with an up to date Manjaro Linux OS and Sage 9.2 
> successfully compiled from source I failed to install  
> gap_packages-4.10.2.p1, while many other optional packages (like the huge 
> cbc) installed perfectly. Below I append the (hopefully) relevant piece of 
> the log file.
> 
> -- Peter Mueller
> 
> [...]
> gcc -c -O -fno-builtin nqmfns.c 
> gcc -O -fno-builtin -o ..//..//bin/x86_64-pc-linux-gnu-default64-kv3/nqmrun 
> nqmd.o nqmp.o nqmfns.o
> /usr/bin/ld: nqmfns.o:(.bss+0x8): multiple definition of `ip'; 
> nqmp.o:(.bss+0x8): first defined here
> /usr/bin/ld: nqmfns.o:(.bss+0x0): multiple definition of `op'; 
> nqmp.o:(.bss+0x0): first defined here
> collect2: error: ld returned 1 exit status
> make[4]: *** [makefile:49: 
> ..//..//bin/x86_64-pc-linux-gnu-default64-kv3/nqmrun] Error 1
> make[3]: *** [Makefile:9: all] Error 2
> 
> Error building gap_packages-4.10.2.p1
> [...]
> 
> (I don't know if that matters, but the log also contains 201 warnings, all 
> about implicit declarations of functions.)
> 
> 
> -- 
> 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/0ae1e161-1e1e-4da9-a7f5-2e106e74caeco%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/38E09832-AFC6-4788-AB7D-A14DBB2FEC91%40gmail.com.

Re: [sage-devel] zenodo (DOI) for Sage releases is back!

[François Bissey]

That’s nice but it looks like there could be improvement to the authors’ list.
Some people appear by handle rather than name. Is it because they don’t give 
their real
names on GitHub? Or don’t have a GitHub account? It also looks truncated.

> On 7/10/2020, at 9:46 AM, Dima Pasechnik  wrote:
> 
> We've recovered the settings for getting DOI for Sage releases via
> zenodo, something that was broken for years.
> cf https://zenodo.org/record/4066866
> and this is DOI for Sage 9.1: https://doi.org/10.5281/zenodo.4066866
> 
> -- 
> 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/CAAWYfq1%2BmY1uULNUsEXwOk8rVyYVJ0%3DxJ9EoRp2naDFz7o99xg%40mail.gmail.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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/54FC8789-0BA0-4CC6-A273-34E55CB94785%40gmail.com.

Re: [sage-devel] configure fails to find some packages (archlinux)

[François Bissey]

I have just posted some musing on the issue on GitHub.

> On 23/09/2020, at 10:28 PM, Antonio Rojas  wrote:
> 
> 
> 
> 
> There is also something funny with Flint 2.6 build using cmake - not 
> sure if it's the case on your system, but it seems 
> that in this case there is no way to specify whether you want GC 
> support or not. 
> I guess it ends up without GC support (or, perhaps, with GC support, 
> no idea), while not setting the corresponding HAVE_GC define. See 
> https://github.com/wbhart/flint2/issues/837 - my question there is 
> unanswered. 
> 
> 
> Indeed, there's no HAVE_GC in flint-config.h and flint is not linked to 
> libgc.so 
> 
> -- 
> 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/3d515529-6df4-41db-9cb3-468573e463a7n%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/5E03B438-92B8-4542-9F6B-65319B716225%40gmail.com.

Re: [sage-devel] packaging sage on void linux

[François Bissey]

I cannot talk for all distress but in Gentoo (and I believe at least arch) I 
build everything
as system packages. Which means that some have to be a particular version or 
include specific
patches.
The sagemath library - the python stuff - is then built and installed as a 
regular python package.
Some adjustments are necessary to make it work.
https://github.com/cschwan/sage-on-gentoo/tree/master/sci-mathematics/sage

François

> On 26/08/2020, at 3:37 AM, Nicolo' Piazzalunga  
> wrote:
> 
> We are now able to build sage on void linux by using ./bootstrap, ./configure 
> and make; everything is installed in some local folder, since make install is 
> a no-op.
> 
> 
> Trying to package it, using as many system packages as possible, and taking 
> advantage of its build and configure features,
> is it possible (1) to just move the whole thing, by copying some files to the 
> appropriate /usr/bin (or similar) and making some changes?
> or is it better (2) to translate the configure/build scripts into the 
> xbps-source (Void Linux native packaging system, [1]) language, such that for 
> example one can still use ./configure, but what it does is instruct 
> xbps-source to build missing packages as system packages with appropriate 
> build options?
> 
> 
> Thanks.
> 
> 
> [1] https://github.com/void-linux/void-packages/blob/master/Manual.md
> 
> -- 
> 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/5a6bfe5a-a9a9-6838-0068-bda813205d67%40gmail.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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/A37DE9E5-20A8-4C99-AC78-241D16A9EDEA%40gmail.com.

Re: [sage-devel] make doc gets stuck at thematic_tutorials

[François Bissey]

You are probably experiencing https://trac.sagemath.org/ticket/30351

> On 18/08/2020, at 12:28 PM, Zachary Scherr  wrote:
> 
> I tried to build the documentation on 9.2 beta 8 and the documentation 
> building seems to get hang on:
> 
> [dochtml]
> [dochtml] [thematic_] building [html]: targets for 83 source files that are 
> out of date
> [dochtml] [thematic_] updating environment: [new config] 83 added, 0 changed, 
> 0 removed
> 
> When I hit ctrl+C I got:
> 
> ^C[dochtml] Error building the documentation.
> [dochtml] Traceback (most recent call last):
> [dochtml]   File 
> "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.7/lib/python3.7/runpy.py",
>  line 193, in _run_module_as_main
> [dochtml] "__main__", mod_spec)
> [dochtml]   File 
> "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.7/lib/python3.7/runpy.py",
>  line 85, in _run_code
> [dochtml] exec(code, run_globals)
> [dochtml]   File 
> "/Users/zscherr/sage/develop/local/lib/python3.7/site-packages/sage_setup/docbuild/__main__.py",
>  line 2, in 
> [dochtml] main()
> [dochtml]   File 
> "/Users/zscherr/sage/develop/local/lib/python3.7/site-packages/sage_setup/docbuild/__init__.py",
>  line 1721, in main
> [dochtml] builder()
> [dochtml]   File 
> "/Users/zscherr/sage/develop/local/lib/python3.7/site-packages/sage_setup/docbuild/__init__.py",
>  line 337, in _wrapper
> [dochtml] build_many(build_other_doc, L)
> [dochtml]   File 
> "/Users/zscherr/sage/develop/local/lib/python3.7/site-packages/sage_setup/docbuild/__init__.py",
>  line 281, in build_many
> [dochtml] _build_many(target, args, processes=NUM_THREADS)
> [dochtml]   File 
> "/Users/zscherr/sage/develop/local/lib/python3.7/site-packages/sage_setup/docbuild/utils.py",
>  line 263, in build_many
> [dochtml] waited_pid, waited_exitcode = wait_for_one()
> [dochtml]   File 
> "/Users/zscherr/sage/develop/local/lib/python3.7/site-packages/sage_setup/docbuild/utils.py",
>  line 179, in wait_for_one
> [dochtml] pid, sts = os.wait()
> [dochtml]   File "src/cysignals/signals.pyx", line 320, in 
> cysignals.signals.python_check_interrupt
> [dochtml] KeyboardInterrupt
> 
> any ideas?
> 
> 
> 
> -- 
> 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/542ad0c5-acd5-4cd5-aa8b-66cc711c9facn%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/2BD5635B-8B18-46C3-831C-4CA85DEF4827%40gmail.com.

Re: [sage-devel] problem building ecl on osx

[François Bissey]

Looks like a missing makeinfo problem. I thought we had a fix for that included.
But I only poorly followed the ecl upgrade ticket due to other commitments.

> On 19/07/2020, at 12:50 PM, David Einstein  wrote:
> 
> Attempting to rebuild sage I run into problems building ecl.  This baffles 
> me, as it seems to die while building the documentation for ecl.
> Attached are the config.log and ecl-20.4.24.p0.log
> 
> -- 
> 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/ca800d1f-eb47-4a18-af28-3a64a01f9241o%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/1EC4563A-C498-48E4-A6A6-8B249F4B1428%40gmail.com.

[sage-devel] leave

[François Bissey]

Hi all,

I will be of the map until Monday-Tuesday next week.
I won’t be available for reviews until then.

François

-- 
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/E8760B95-D0F8-4EF1-8E26-0DB12FED61F4%40gmail.com.

Re: [sage-devel] Linking to libstdc++

[François Bissey]

+1 - it should at least be tried.

> On 14/06/2020, at 7:55 PM, Dima Pasechnik  wrote:
> 
> Probably can be just removed.

-- 
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/FD30818B-7F1C-48FD-9FEC-F40985DEEC45%40gmail.com.

Re: [sage-devel] Linking to libstdc++

[François Bissey]

> On 14/06/2020, at 4:25 PM, Isuru Fernando  wrote:
> 
> Yes, it was probably NTL related. 
> https://github.com/sagemath/sage/commit/bc333c78b0369377657452e340cb6b3f27c5cee0
> 

Nice digging. libcsage is no more and it’s been a while. 


> I think distutils now knows to link with the C++ compiler even though it 
> compiles C++ sources with a C compiler. OSX build works fine without `libc++` 
> being linked in explicitly, so that must mean that we are using clang++ on 
> OSX at the correct place, right?
> 

I would think so. 

François

-- 
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/55AFB8E6-5605-4EB6-AE21-D84EBB0DD233%40gmail.com.

Re: [sage-devel] Linking to libstdc++

[François Bissey]

That far back? It was probably something like ntl or singular (or something 
that has since then
been removed) that didn’t link properly.
More seriously, it may have been because the linker used was gcc instead of g++ 
even when linking
C++ code. We know there is/was that issue about C/C++ compiler in distutils (I 
haven’t been keeping
track, are we still patching python for that in distros?).  

> On 14/06/2020, at 4:03 PM, Isuru Fernando  wrote:
> 
> Hi,
> 
> Anybody know why sage is linking to libstdc++? 
> 
> https://github.com/sagemath/sage/blob/cdb4c0b073efce77b08de4aa24df6583cdb74fa3/src/setup.py#L371-L374
> 
> In OSX, we don't need libstdc++, because we are using libc++. Git history 
> says it was added 13 years ago by William Stein.
> 
> Isuru
> 
> -- 
> 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%2B01voM7gDVO%3DAxbCJMXM2dqrufkDhHH1EqsDsP15%2Byo8e6KFw%40mail.gmail.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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/57A33493-F93D-4A71-A8F4-AB6DC2417A22%40gmail.com.

Re: [sage-devel] New Python version requirement for Sage?

[François Bissey]

Sage was building with py 3.6 but no python 3 lower than that a few month ago.
I don’t know if it still builds with 3.6.
The officially supported python that pass the doctest suite is python 3.7. 
3.6 would spout a number of broken doctests (but mostly run as far as I could 
tell).

> On 28/05/2020, at 8:49 AM, Dima Pasechnik  wrote:
> 
> On Wed, May 27, 2020 at 9:08 PM Volker Braun  wrote:
>> 
>> Which python versions do we want to be compatible with now? Please separate
>> 
>> 
>> A) Supported Python versions for building Sage
>> 
>> Note that I'm already seeing f-strings in #29547 so unless a policy is 
>> formulated real soon the de-facto answer is going to be Python 3.6+
> 
> yes, this makes sense.
> 
>> 
>> 
>> B) Supported Python versions for running Sage
>> 
>> The default answer for B) is whatever is in 
>> build/pkgs/python3/package-version.txt, of course
> 
> I think it's 3.7.x, for x>2.
> 
>> 
>> --
>> 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/94cfccfd-aba2-467e-adbf-646e0889fa87%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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/CAAWYfq0JfORf8SW%3Dad9EMcjsM0Nfc7QpdiYOouv4M_cB4GXqNg%40mail.gmail.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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/40C54614-4B8E-461F-A714-646A60732096%40gmail.com.

Re: [sage-devel] Pre-Announcement: Global Virtual SageDays 109 - May 28, 2020 (all timezones)

[François Bissey]

Indeed! I am part of HPCCF (HPC certification forum) and at the beginning of 
the week
we had some kind of assembly. In two parts.
UK->Americas on Monday [would have turned out as 2am Tuesday for me]
UK->NZ on Wednesday [it was still 8pm to 10pm for NZ-ers like me]

> On 22/05/2020, at 8:13 AM, Dima Pasechnik  wrote:
> 
> well, yes, it's a well-known problem, that EU+US+NZ online meetings
> are basically impossible to schedule :-(
> 
> 

-- 
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/1280F920-3DE7-4B81-BA73-D5600D1B8B51%40gmail.com.

Re: [sage-devel] Pre-Announcement: Global Virtual SageDays 109 - May 28, 2020 (all timezones)

[François Bissey]

Hum. May 21, 19:30GMT = May 22 7:30 NZ time I was in the middle of preparing 
breakfast
for the kids and we should go to school shortly.
Needless to say I won’t participate at 7:30am on a Saturday morning.

François

> On 22/05/2020, at 7:57 AM, Matthias Koeppe  wrote:
> 
> On Thursday, May 21, 2020 at 10:04:26 AM UTC-7, Matthias Koeppe wrote:
> The Global Virtual SageDays 109 will be held on May 28, 2020 (all timezones).
> 
> I have updated https://wiki.sagemath.org/days109 and created the stream 
> #sd109 on https://zulip.sagemath.org/
> 
> 
> People interested in helping with the organization, or contributing 
> presentations, please respond here or on zulip.
> 
> For synchronous communication, let's meet TODAY, May 21, 19:30 GMT = 21:30 
> CEST = 15:30 EDT = 12:30 PDT on zulip.
> 
> 
> Next organization meeting = Friday May 22, 19:30 GMT = 21:30 CEST = 15:30 EDT 
> = 12:30 PDT on zulip.
> 
>  
> 
> -- 
> 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/0be3d70e-2ea2-4c80-ae19-4a62a23f59ab%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/A793A3B9-D6AE-46AE-BBA2-B25915118212%40gmail.com.

Re: [sage-devel] Packaging Sage?

[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.

Re: [sage-devel] sagenb dependencies

[François Bissey]

The flask packages definitely should be made optional.

> On 12/03/2020, at 12:02 PM, Antonio Rojas  wrote:
> 
> sagenb was made optional, but its dependencies (such as flask-* packages) are 
> still standard and installed by default as of 9.1.beta7. Shouldn't they be 
> made optional too?
> 
> -- 
> 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/407283bd-e470-488d-aff0-02beff21141e%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/F7E863CF-C0CB-4DF1-BA69-EEBA80B9B01D%40gmail.com.