Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[Matthias Koeppe]

On Friday, September 9, 2022 at 9:34:16 PM UTC-7 Travis Scrimshaw wrote:

> I really dislike Github's decentralized approach with PR and having to 
> have separate clones of the repo within each user. My understanding is if 
> two people have different fixes, then they individually submit PRs that are 
> not explicitly linked with each other, much less with a specific bug report 
> issue. 


In the PR you would include a comment such as "Fixes #1234", which links it 
to an Issue (bug report).
Yes, there can be multiple competing PRs in order solve one ticket. Better 
than edit wars on a Trac 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/2548301a-19d8-4ab5-ab1c-84f3fdcf5bbcn%40googlegroups.com.

Re: [sage-devel] nauty_gentourng is not available

[Jakub Sliacan]

Just to update: I compiled 9.6 from source and everything's as expected. 
Thanks

On Saturday, 10 September 2022 at 01:05:07 UTC+2 Jakub Sliacan wrote:

> Thanks Dima,
>
> Opened an issue as you suggested: 
> https://bugzilla.redhat.com/show_bug.cgi?id=2125737. I'm surprised nobody 
> else has hit the same issue yet, I just tried sage 9.4 and I can't get 
> nauty generators to work either (slightly different behavior though). 
>
> Anyways, thanks again.
> Jakub
>
> On Saturday, 10 September 2022 at 00:23:57 UTC+2 dim...@gmail.com wrote:
>
>> Hi Jakub,
>> this looks like a Fedora packaging problem.
>> Please report it to them.
>> Dima
>>
>>
>> On Fri, 9 Sep 2022, 23:12 Jakub Sliacan,  wrote:
>>
>>> Hi!
>>>
>>> I'm using sage 9.6 on Fedora 36, installed via dnf. I am seeing the 
>>> following. The version of nauty package that I see installed is 
>>> nauty-2.7.4-1.fc36.x86_64. 
>>>
>>> ```
>>> sage: for t in digraphs.tournaments_nauty(6):
>>> : print(t)
>>> : 
>>>
>>> ---
>>> FeatureNotPresentErrorTraceback (most recent call 
>>> last)
>>> Input In [1], in ()
>>> > 1 for t in digraphs.tournaments_nauty(Integer(6)):
>>>   2 print(t)
>>>
>>> File 
>>> /usr/lib64/python3.10/site-packages/sage/graphs/digraph_generators.py:532, 
>>> in DiGraphGenerators.tournaments_nauty(self, n, min_out_degree, 
>>> max_out_degree, strongly_connected, debug, options)
>>> 530 import shlex
>>> 531 from sage.features.nauty import NautyExecutable
>>> --> 532 gentourng_path = NautyExecutable("gentourng").absolute_filename()
>>> 534 sp = subprocess.Popen(shlex.quote(gentourng_path) + " 
>>> {0}".format(nauty_input),
>>> 535   shell=True,
>>> 536   stdin=subprocess.PIPE, 
>>> stdout=subprocess.PIPE,
>>> 537   stderr=subprocess.PIPE, close_fds=True)
>>> 539 if debug:
>>>
>>> File /usr/lib64/python3.10/site-packages/sage/features/__init__.py:619, 
>>> in Executable.absolute_filename(self)
>>> 617 if path is not None:
>>> 618 return path
>>> --> 619 raise FeatureNotPresentError(self,
>>> 620  reason="Executable {executable!r} 
>>> not found on PATH.".format(executable=self.executable),
>>> 621  resolution=self.resolution())
>>>
>>> FeatureNotPresentError: nauty_gentourng is not available.
>>> Executable 'gentourng' not found on PATH.
>>> No equivalent system packages for pip are known to Sage.
>>> ```
>>> It seems like no generators based on nauty are available, as I get the 
>>> same error with `geng` if I want to access items from 
>>> `graphs.nauty_geng("2")`. 
>>>
>>> If I recall correctly, there were no additional (installation) steps 
>>> needed for these things to work in e.g. Sage 8.3. And I can't find any 
>>> notes about this afterwards. Any help is much appreciated! 
>>>
>>> Thanks in advance,
>>> Jakub
>>>
>>> -- 
>>> 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/73f2313f-db93-4db0-bbae-9153f0603c42n%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/1fe8eca6-9150-49e5-b6e3-e0c7e0688b97n%40googlegroups.com.

Re: [sage-devel] Re: docstring of _element_constructor_

['Travis Scrimshaw' via sage-devel]

I try to make sure the ways (I first typed methods, but then realized this 
was confusing) to construct the elements is available either in the parent 
and/or element level documentation by way of examples (maybe saying, "We 
can construct a foo by giving it a list::").

Best,
Travis

On Saturday, September 10, 2022 at 1:07:27 AM UTC+9 dim...@gmail.com wrote:

> On Fri, Sep 9, 2022 at 4:43 PM davida...@gmail.com
>  wrote:
> >
> > I believe that the functionalities given by the method 
> _element_constructor_ should be at least mentioned in the main docstring of 
> the Parent.
> >
> > For example, when typing:
> >
> > sage: QQ?
> >
> > Then, the ouput explains to the user how to construct a rational number. 
> This is how I always used Sage. The documentation of _element_constructor_ 
> would be there for the developers that need to understand and modify it.
>
> Well, _things are internal, and not required to be documented.
>
> >
> > Le vendredi 9 septembre 2022 à 05:16:27 UTC-4, axio...@yahoo.de a écrit 
> :
> >>
> >> Dear all,
> >>
> >> as a user, how am I supposed to access the docstring of an 
> _element_constructor_?
> >>
> >> For example,
> >>
> >> sage: P. = QQ[]
> >> sage: P?
> >>
> >> does not give me any hint about the various ways to construct a 
> polynomial.
> >>
> >> If this is not possible other than "R._element_constructor_?", then, as 
> developers, how should we make this documentation accessible?
> >>
> >> 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/ecf3daf3-0050-4255-84cc-472881a37e0en%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/16f92c24-d12d-475e-a4a5-ed291c357ae9n%40googlegroups.com.

[sage-devel] Re: load deprecation warning in SageCell

[Mike]

Thank you for the suggestion, but I'd rather change the cell content as 
little as possible. I'm trying to present a simple interface to my freshmen 
students, so I think it'll be easier to tell them to ignore the warnings 
than to explain the extra code.  (I was hoping the load command might have 
an "ignore warnings" option.)

On Wednesday, September 7, 2022 at 7:10:02 PM UTC-4 Nils Bruin wrote:

> On Tuesday, 24 May 2022 at 11:10:13 UTC-7 ingo...@gmail.com wrote:
>
>> When I call
>> *load('https://raw.githubusercontent.com/ingodahn/sageutils/master/physics.py
>>  
>> ')*
>> in a sagecell I get in the output
>> */home/sc_serv/sage/local/var/lib/sage/venv-python3.10.3/lib/python3.10/site-packages/sage/misc/remote_file.py:46:
>>  
>> DeprecationWarning: ssl.SSLContext() without protocol argument is 
>> deprecated. content = urlopen(req, timeout=1, context=SSLContext())*
>>
>> How can I avoid this message?
>>
>>
> If you're OK with changing the cell content, you can use python's standard 
> warning control infrastructure to suppress the message. For instance, the 
> following silences any warnings that would arise from the "load" invocation:
>  
> import warnings
> with warnings.catch_warnings():
> warnings.simplefilter("ignore")
> load('
> https://raw.githubusercontent.com/ingodahn/sageutils/master/physics.py') 
>

-- 
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/a395355d-97d6-4f55-9711-7a641da0a929n%40googlegroups.com.

Re: [sage-devel] nauty_gentourng is not available

[Jakub Sliacan]

Thanks Dima,

Opened an issue as you suggested: 
https://bugzilla.redhat.com/show_bug.cgi?id=2125737. I'm surprised nobody 
else has hit the same issue yet, I just tried sage 9.4 and I can't get 
nauty generators to work either (slightly different behavior though). 

Anyways, thanks again.
Jakub

On Saturday, 10 September 2022 at 00:23:57 UTC+2 dim...@gmail.com wrote:

> Hi Jakub,
> this looks like a Fedora packaging problem.
> Please report it to them.
> Dima
>
>
> On Fri, 9 Sep 2022, 23:12 Jakub Sliacan,  wrote:
>
>> Hi!
>>
>> I'm using sage 9.6 on Fedora 36, installed via dnf. I am seeing the 
>> following. The version of nauty package that I see installed is 
>> nauty-2.7.4-1.fc36.x86_64. 
>>
>> ```
>> sage: for t in digraphs.tournaments_nauty(6):
>> : print(t)
>> : 
>>
>> ---
>> FeatureNotPresentErrorTraceback (most recent call 
>> last)
>> Input In [1], in ()
>> > 1 for t in digraphs.tournaments_nauty(Integer(6)):
>>   2 print(t)
>>
>> File 
>> /usr/lib64/python3.10/site-packages/sage/graphs/digraph_generators.py:532, 
>> in DiGraphGenerators.tournaments_nauty(self, n, min_out_degree, 
>> max_out_degree, strongly_connected, debug, options)
>> 530 import shlex
>> 531 from sage.features.nauty import NautyExecutable
>> --> 532 gentourng_path = NautyExecutable("gentourng").absolute_filename()
>> 534 sp = subprocess.Popen(shlex.quote(gentourng_path) + " 
>> {0}".format(nauty_input),
>> 535   shell=True,
>> 536   stdin=subprocess.PIPE, 
>> stdout=subprocess.PIPE,
>> 537   stderr=subprocess.PIPE, close_fds=True)
>> 539 if debug:
>>
>> File /usr/lib64/python3.10/site-packages/sage/features/__init__.py:619, 
>> in Executable.absolute_filename(self)
>> 617 if path is not None:
>> 618 return path
>> --> 619 raise FeatureNotPresentError(self,
>> 620  reason="Executable {executable!r} 
>> not found on PATH.".format(executable=self.executable),
>> 621  resolution=self.resolution())
>>
>> FeatureNotPresentError: nauty_gentourng is not available.
>> Executable 'gentourng' not found on PATH.
>> No equivalent system packages for pip are known to Sage.
>> ```
>> It seems like no generators based on nauty are available, as I get the 
>> same error with `geng` if I want to access items from 
>> `graphs.nauty_geng("2")`. 
>>
>> If I recall correctly, there were no additional (installation) steps 
>> needed for these things to work in e.g. Sage 8.3. And I can't find any 
>> notes about this afterwards. Any help is much appreciated! 
>>
>> Thanks in advance,
>> Jakub
>>
>> -- 
>> 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/73f2313f-db93-4db0-bbae-9153f0603c42n%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/3e06a0d6-5341-4cdd-a911-1fa70bf5aeb0n%40googlegroups.com.

Re: [sage-devel] nauty_gentourng is not available

[Dima Pasechnik]

Hi Jakub,
this looks like a Fedora packaging problem.
Please report it to them.
Dima


On Fri, 9 Sep 2022, 23:12 Jakub Sliacan,  wrote:

> Hi!
>
> I'm using sage 9.6 on Fedora 36, installed via dnf. I am seeing the
> following. The version of nauty package that I see installed is
> nauty-2.7.4-1.fc36.x86_64.
>
> ```
> sage: for t in digraphs.tournaments_nauty(6):
> : print(t)
> :
> ---
> FeatureNotPresentErrorTraceback (most recent call last)
> Input In [1], in ()
> > 1 for t in digraphs.tournaments_nauty(Integer(6)):
>   2 print(t)
>
> File
> /usr/lib64/python3.10/site-packages/sage/graphs/digraph_generators.py:532,
> in DiGraphGenerators.tournaments_nauty(self, n, min_out_degree,
> max_out_degree, strongly_connected, debug, options)
> 530 import shlex
> 531 from sage.features.nauty import NautyExecutable
> --> 532 gentourng_path = NautyExecutable("gentourng").absolute_filename()
> 534 sp = subprocess.Popen(shlex.quote(gentourng_path) + "
> {0}".format(nauty_input),
> 535   shell=True,
> 536   stdin=subprocess.PIPE,
> stdout=subprocess.PIPE,
> 537   stderr=subprocess.PIPE, close_fds=True)
> 539 if debug:
>
> File /usr/lib64/python3.10/site-packages/sage/features/__init__.py:619, in
> Executable.absolute_filename(self)
> 617 if path is not None:
> 618 return path
> --> 619 raise FeatureNotPresentError(self,
> 620  reason="Executable {executable!r} not
> found on PATH.".format(executable=self.executable),
> 621  resolution=self.resolution())
>
> FeatureNotPresentError: nauty_gentourng is not available.
> Executable 'gentourng' not found on PATH.
> No equivalent system packages for pip are known to Sage.
> ```
> It seems like no generators based on nauty are available, as I get the
> same error with `geng` if I want to access items from
> `graphs.nauty_geng("2")`.
>
> If I recall correctly, there were no additional (installation) steps
> needed for these things to work in e.g. Sage 8.3. And I can't find any
> notes about this afterwards. Any help is much appreciated!
>
> Thanks in advance,
> Jakub
>
> --
> 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/73f2313f-db93-4db0-bbae-9153f0603c42n%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/CAAWYfq11bEREH9jyVmzW_%3DpV1XHaYqKkv2CoxU-6hKT83ni9kQ%40mail.gmail.com.

[sage-devel] nauty_gentourng is not available

[Jakub Sliacan]

Hi!

I'm using sage 9.6 on Fedora 36, installed via dnf. I am seeing the 
following. The version of nauty package that I see installed is 
nauty-2.7.4-1.fc36.x86_64. 

```
sage: for t in digraphs.tournaments_nauty(6):
: print(t)
: 
---
FeatureNotPresentErrorTraceback (most recent call last)
Input In [1], in ()
> 1 for t in digraphs.tournaments_nauty(Integer(6)):
  2 print(t)

File 
/usr/lib64/python3.10/site-packages/sage/graphs/digraph_generators.py:532, 
in DiGraphGenerators.tournaments_nauty(self, n, min_out_degree, 
max_out_degree, strongly_connected, debug, options)
530 import shlex
531 from sage.features.nauty import NautyExecutable
--> 532 gentourng_path = NautyExecutable("gentourng").absolute_filename()
534 sp = subprocess.Popen(shlex.quote(gentourng_path) + " 
{0}".format(nauty_input),
535   shell=True,
536   stdin=subprocess.PIPE, stdout=subprocess.PIPE,
537   stderr=subprocess.PIPE, close_fds=True)
539 if debug:

File /usr/lib64/python3.10/site-packages/sage/features/__init__.py:619, in 
Executable.absolute_filename(self)
617 if path is not None:
618 return path
--> 619 raise FeatureNotPresentError(self,
620  reason="Executable {executable!r} not 
found on PATH.".format(executable=self.executable),
621  resolution=self.resolution())

FeatureNotPresentError: nauty_gentourng is not available.
Executable 'gentourng' not found on PATH.
No equivalent system packages for pip are known to Sage.
```
It seems like no generators based on nauty are available, as I get the same 
error with `geng` if I want to access items from `graphs.nauty_geng("2")`. 

If I recall correctly, there were no additional (installation) steps needed 
for these things to work in e.g. Sage 8.3. And I can't find any notes about 
this afterwards. Any help is much appreciated! 

Thanks in advance,
Jakub

-- 
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/73f2313f-db93-4db0-bbae-9153f0603c42n%40googlegroups.com.

Re: [sage-devel] Fwd: request for help: macOS PARI binaries

[William Stein]

+1 from me.

On Fri, Sep 9, 2022 at 9:18 AM Dima Pasechnik  wrote:
>
> On Thu, Sep 8, 2022 at 10:40 AM Samuel Lelievre
>  wrote:
> >
> > Echoing a message posted to the pari-users mailing list.
> >
> > https://pari.math.u-bordeaux.fr/archives/pari-users-2209/msg00015.html
> >
> >
> > -- Forwarded message (slightly edited) -
> > From: Bill Allombert
> > Date: 2022-09-08 07:15 UTC
> > Subject: request for help: MacOS PARI binaries
> > To: pari-users
> >
> >
> > Dear PARI users,
> >
> > We do not have the support needed to build
> > macOS binary for the ARM based Mac. We both
> > lack the hardware and the software expertise
> > to set up a new build system for newer Mac.
> >
> > What we would need is access to a Mac mini
> > with Xcode and Homebrew installed, and help
> > with updating our build scripts for M1.
>
> Maybe we should provide money from our little war chest to pay for M1
> hardware for Pari/GP
> group and Sage people - to be hosted in Bordeaux?
>
> Dima
>
> >
> > Cheers,
> > Bill.
> >
> > --
> > 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/82a6ee87-fff4-46da-9499-a611b3d19d11n%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/CAAWYfq2xxEmY4qw-Zu12moRBrhgqJjzO7CoUDMXyCxAaD491Bw%40mail.gmail.com.



-- 
William (http://wstein.org)

-- 
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/CACLE5GAuHHRCBJUtt_T7sFsLS-U-uBRD7-afPGP-8xa3jrWhQg%40mail.gmail.com.

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[Dima Pasechnik]

On Fri, Sep 9, 2022 at 7:58 PM Thierry  wrote:
>
> On Fri, Sep 09, 2022 at 04:07:48PM +0100, Dima Pasechnik wrote:
> [...]
> >
> > Several people promised to look for academic hosting for trac. Nothing
> > came out of it.
>
> Please do not rewrite history, as it adds violence to violence. There
> have indeed been offers for academic hosting, the VM were ready, but the
> cloud hosting was enforced, and you was promoting this.

I don't recall any concrete offer like this. If I recall correctly,
the problem of accessing VMs in French
universities for outsiders have never been resolved in a meaningful
way, leading to an unacceptably small
for the project bus factor.

By the way, another proof of my small bus factor claim is here:
https://trac.sagemath.org/ticket/33725#comment:30
Apparently you want to do everything your way, and your way only.
You are asked to provide the wiki contents in a suitable for import
form, and you just pretend you didn't see the request?


Dima



>
> Ciao,
> Thierry
>
> --
> 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/20220909185835.GA20878%40metelu.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/CAAWYfq32az4qPADzJZ0cY-jV%3DphQockhtVEMVjaUmuuZgp-jpw%40mail.gmail.com.

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[Thierry]

On Fri, Sep 09, 2022 at 04:07:48PM +0100, Dima Pasechnik wrote:
[...]
> 
> Several people promised to look for academic hosting for trac. Nothing
> came out of it.

Please do not rewrite history, as it adds violence to violence. There
have indeed been offers for academic hosting, the VM were ready, but the
cloud hosting was enforced, and you was promoting this.

Ciao,
Thierry

-- 
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/20220909185835.GA20878%40metelu.net.

Re: [sage-devel] Bug in decomposition_type

[David Roe]

Thanks for the report.  There's a fix at #34514
, needs review.
David

On Fri, Sep 9, 2022 at 5:17 AM Björn Selander  wrote:

> Hi,
>
> running the Sage script
>
> K. = NumberField(x^4 + 18*x^2 - 1)
> R. = K[]
> L. = K.extension(y^2 + 9*a^3 - 2*a^2 + 162*a - 38)
>
> dt = [L.decomposition_type(i) for i in K.primes_above(3)]
> print(dt)
>
> gives the output
>
> [[(1, 1, 2)], [(1, 1, 2)], [(1, 1, 1)]]
>
> The third element in the list ought to be nonsense. Certainly the products
> of the entries of all sublists should be 2.
>
> Regards
> Björn
>
> --
> 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/a875cd6e-37ec-49e3-a85a-b84b33b37983n%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/CAChs6_nAL2bs52zdwpUBGebiz-oA-xq0WLyz_h4iJDiBoEzH0Q%40mail.gmail.com.

Re: [sage-devel] Fwd: request for help: macOS PARI binaries

[Dima Pasechnik]

On Thu, Sep 8, 2022 at 10:40 AM Samuel Lelievre
 wrote:
>
> Echoing a message posted to the pari-users mailing list.
>
> https://pari.math.u-bordeaux.fr/archives/pari-users-2209/msg00015.html
>
>
> -- Forwarded message (slightly edited) -
> From: Bill Allombert
> Date: 2022-09-08 07:15 UTC
> Subject: request for help: MacOS PARI binaries
> To: pari-users
>
>
> Dear PARI users,
>
> We do not have the support needed to build
> macOS binary for the ARM based Mac. We both
> lack the hardware and the software expertise
> to set up a new build system for newer Mac.
>
> What we would need is access to a Mac mini
> with Xcode and Homebrew installed, and help
> with updating our build scripts for M1.

Maybe we should provide money from our little war chest to pay for M1
hardware for Pari/GP
group and Sage people - to be hosted in Bordeaux?

Dima

>
> Cheers,
> Bill.
>
> --
> 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/82a6ee87-fff4-46da-9499-a611b3d19d11n%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/CAAWYfq2xxEmY4qw-Zu12moRBrhgqJjzO7CoUDMXyCxAaD491Bw%40mail.gmail.com.

Re: [sage-devel] Re: docstring of _element_constructor_

[Dima Pasechnik]

On Fri, Sep 9, 2022 at 4:43 PM davida...@gmail.com
 wrote:
>
> I believe that the functionalities given by the method _element_constructor_ 
> should be at least mentioned in the main docstring of the Parent.
>
> For example, when typing:
>
> sage: QQ?
>
> Then, the ouput explains to the user how to construct a rational number. This 
> is how I always used Sage. The documentation of _element_constructor_ would 
> be there for the developers that need to understand and modify it.

Well, _things are internal, and not required to be documented.

>
> Le vendredi 9 septembre 2022 à 05:16:27 UTC-4, axio...@yahoo.de a écrit :
>>
>> Dear all,
>>
>> as a user, how am I supposed to access the docstring of an 
>> _element_constructor_?
>>
>> For example,
>>
>> sage: P. = QQ[]
>> sage: P?
>>
>> does not give me any hint about the various ways to construct a polynomial.
>>
>> If this is not possible other than "R._element_constructor_?", then, as 
>> developers, how should we make this documentation accessible?
>>
>> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/ecf3daf3-0050-4255-84cc-472881a37e0en%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/CAAWYfq19hRHeVNVYfgSchQ3DY2PRnQP427ykHoo2H0tuPvrCiQ%40mail.gmail.com.

[sage-devel] Re: docstring of _element_constructor_

[davida...@gmail.com]

I believe that the functionalities given by the method 
_element_constructor_ should be at least mentioned in the main docstring of 
the Parent.

For example, when typing:

sage: QQ?

Then, the ouput explains to the user how to construct a rational number. 
This is how I always used Sage. The documentation of _element_constructor_ 
would be there for the developers that need to understand and modify it.

Le vendredi 9 septembre 2022 à 05:16:27 UTC-4, axio...@yahoo.de a écrit :

> Dear all,
>
> as a user, how am I supposed to access the docstring of an 
> _element_constructor_?
>
> For example,
>
> sage: P. = QQ[]
> sage: P?
>
> does not give me any hint about the various ways to construct a polynomial.
>
> If this is not possible other than "R._element_constructor_?", then, as 
> developers, how should we make this documentation accessible?
>
> 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/ecf3daf3-0050-4255-84cc-472881a37e0en%40googlegroups.com.

Re: [sagemath-admins] Fwd: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[Dima Pasechnik]

On Fri, Sep 9, 2022 at 4:06 PM John Cremona  wrote:
>
> To me, as a contributor of code to Sage who has not contributed at all
> to the backend support, it seems that there is a clear majority in
> favour of moving to github.  As an ordinary developer I would be very
> happy with that.
>
> It looks to me as if Frédéric's main issue with github is his final
> point "...We should rather not bow under the power of large
> private companies.".

my reply to Frederic got posted ahead of his post, as he didn't cc to
sage-devel.
I wrote there that I don't see how to consolidate the latter wish with
us currently paying a huge private
corporation, and a rather evil one, a figure of about US$4000 p.a . for hosting.


>  I don't know enough about gitlab to know if it
> is a sensible alternative, but I myself have no problem with using
> github for this, as I do for just about everything else.
>
> John
>
> On Fri, 9 Sept 2022 at 15:10, Thierry  wrote:
> >
> > Hi,
> >
> > let me forward the email of Frédéric as a whole, so that the thread remains
> > complete.
> >
> > - Forwarded message from Frédéric Chapoton  -
> >
> > Date: Fri, 9 Sep 2022 12:15:25 +0200
> > From: Frédéric Chapoton
> > To: sagemath-adm...@googlegroups.com
> > Subject: Re: [sagemath-admins] Fwd: [sage-devel] Re: incremental migration
> > to github? [prompted by FUNDING issues!!!] + general flakiness of trac
> >
> > Dear sage developers and maintainers,
> >
> > Whereas I agree that we currently have two issues, I do not agree on the
> > necessity to switch to github and certainly not urgently.
> >
> > * The first issue is the cost of google compute engine. This is under
> > investigation and can be lowered by creating a new project. This should be
> > do-able and could save us 3 $ per day.
> > * The second issue is about new users entering new ssh keys. There is hope
> > to fix that and in the mean-time one could ask new users to send sshkeys to
> > some of us.
> >
> > My own preference would be to go on using trac, for some years, as this is
> > serving us quite well. We should not change this for superficial and
> > temporary reasons.
> >
> > The serious reasons that I see are : money and the futre of the trac
> > software itself.
> >
> > In my opinion, money is the only serious issue, and I would like to see
> > trac heberged by some university. There are already several services in
> > France, so another country would be better. Germany ? Somebody must step
> > forward.
> >
> > About the trac software, it now has a python3-compatible version, available
> > on most linux distributions. We should aim to use that. Once done, the
> > situation will be stable.
> >
> > As a side matter, it seems to me that gitlab is much more in the spirit of
> > open source software. We should rather not bow under the power of large
> > private companies.
> >
> > Frédéric
> >
> > -
> >
> >
> >
> > On Fri, Sep 09, 2022 at 12:15:13PM +0100, Dima Pasechnik wrote:
> > > On Fri, Sep 9, 2022 at 11:15 AM Frédéric Chapoton  
> > > wrote:
> > > >
> > > > Dear sage developers and maintainers,
> > > >
> > > > Whereas I agree that we currently have two issues, I do not agree on 
> > > > the necessity to switch to github and certainly not urgently.
> > >
> > > it is a disaster that new people can't come aboard easily. It really is 
> > > urgent.
> > > A convoluted system to get new developers onboard and contributing is
> > > a very bad omen for open-source projects, it really is.
> > >
> > > E.g. try to contribute to something like OpenBSD - I'd sure most
> > > potentail contributors  run away screaming,
> > > upon learning that they must use CVS and e-mail patches around for 
> > > approval.
> > >
> > > >
> > > > * The first issue is the cost of google compute engine. This is under 
> > > > investigation and can be lowered by creating a new project. This should 
> > > > be do-able and could save us 3 $ per day.
> > >
> > > but this is far from free, still, and hosting prices are to go with
> > > the energy prices, up and up.
> > > It's really spending money on a questionable luxury, instead of
> > > something useful.
> > >
> > > > * The second issue is about new users entering new ssh keys. There is 
> > > > hope to fix that and in the mean-time one could ask new users to send 
> > > > sshkeys to some of us.
> > > >
> > > > My own preference would be to go on using trac, for some years, as this 
> > > > is serving us quite well. We should not change this for superficial and 
> > > > temporary reasons.
> > >
> > > the reasons are not supreficial, in particular, trac+gitolite software
> > > is obsolete.
> > > I cannot imagine a new project that would choose it as a platform.
> > >
> > > >
> > > > The serious reasons that I see are : money and the futre of the trac 
> > > > software itself.
> > > >
> > > > In my opinion, money is the only serious issue, and I would like to see 
> > > > trac heberged by some university. There are already several services in 
> > > > France

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[Dima Pasechnik]

On Fri, 9 Sep 2022, 15:48 Thierry,  wrote:

> Hi,
>
> "[prompted by FUNDING issues!!!]" ???
>
> Back in 2016, when cloud hosting was imposed over academic hosting,
> William promised "to pay for it indefinitely", see
> https://groups.google.com/g/sage-devel/c/ed_ya-d-k_E/m/jYoR6opODAAJ
>
> If only for this reason, there is no funding issue.
>

this is bus factor 1 funding. Not good at all.


> The fact is that the the magic cloud ideology turned into a disaster,
> years after years, from askbot in 2014 (thanks again to Niles and OSU
> sysadmins for their involvement in its academic hosting during six
> years !), to the wiki a few months ago, and now trac+git.
>
> I have been involved in rescuing those services, and putting them back
> in a safe place.


OK, so most of these services therefore have bus factor 1.

What do the facts tell us about academic hosting, in
> 2022 ?
>

Several people promised to look for academic hosting for trac. Nothing came
out of it.


> - askbot is academically hosted and works pretty well.
>

for some value of "well". Last time I checked its logins were screwed up,
and dates of posts too.

  Fees to the Sage community: 0$ per year


>
> - patchbot server is academically hosted and works pretty well.
>

you must be kidding here. It's often down, the trac integration is gone.

Most of Sage CI happens on GitHub Actions, anyway.

  Fees to the Sage community: 0$ per year


> - I bet that most patchbot clients are run from academic desktops.
>   Fees to the Sage community: 0$ per year
>
> - wiki is academically hosted and works pretty well.
>

bus factor 1 service.

  Fees to the Sage community: 0$ per year
>
> - the backup server (which currently backs up askbot and wiki) is
>   academically hosted and works pretty well.
>

bus factor 1 service.


>   Fees to the Sage community: 0$ per year
>
> - most download mirrors are academically hosted and work pretty well.

  Fees to the Sage community: 0$ per year
>
> For this reason also, and given the number of universities around the
> world, there is no funding issue. The rest is FUD.
>

FUD? No, me and other people pointed years ago that trac is about to break,
and now it is broken. It's not FUD, it's bad dream that came true,
inevitably.

The very fact that there are half a dozen shabby and differently run
services with bus factor 1 needed to support Sage (and you didn't mention
Google groups, web hosting, DNS, email for sagemath.org - the latter is bus
factor 1 too) indicates it is very fragile and breaking all the time.

And for a newcomer to wrap their head around all them is hardly possible -
as William (and I) wrote, it's  a huge barrier to enter Sage development.


Hence an urgent need for consolidation.

Dima



> Ciao,
> Thierry
>
>
>
> On Fri, Sep 09, 2022 at 02:54:06AM -0700, Dima Pasechnik wrote:
> > I am resurrecting this thread, as in addition of trac continuing to eat
> up
> > funds (at a rate of over US$ 10 per day at the moment), it has gotten
> > increasingly broken. In particular, in the last 2 weeks no new
> developers
> > can really join the project, as there is no normal* way to add new ssh
> keys
> > into trac accounts, and it's not possible to push/pull with "new" github
> > ssh keys, i.e. keys that were not already "known" to trac, i.e. added to
> > the trac store of ssh keys before the last breakage happened.
> >
> > As far as funding is concerned, attempts to bring trac to a "free"
> hosting
> > stalled (see earlier messages in this thread).
> >
> > A further longer term issue is that trac software is basically on life
> > support, and it's only matter of time it will become totally obsolete.
> >
> > Such a move will allow a considerable simplification of our devops, and
> > free up quite a bit of developer time
> > to do interesting work rather than messing around with semi-obsolete
> stuff
> > such as trac, gitolite, etc.
> >
> > Importantly, Volker, the release manager, is willing to proceed with the
> > move.
> >
> > Also, various Sage upstream (and downstream) projects have moved away
> from
> > trac to github, e.g. Cython, or away from another system to github, e.g.
> > CPython, GAP, jupyter, etc...
> >
> > There is a trac ticket to manage the proposed move,
> > https://trac.sagemath.org/ticket/30363 tentatively set for Sage 9.8.
> >
> > I've conducted few experiments with a tool to import trac sites to
> > github: https://github.com/svigerske/trac-to-github, which in
> particular
> > allows to import trac tickets as github issues; a result of running it
> on
> > few tickets
> > may be inspected
> > here:
> https://github.com/dimpase/trac_to_gh/issues?q=is%3Aissue+is%3Aclosed
> > (Here issues 1-10 correspond to trac tickets one to one :-))
> > Further work on trac-to-github will be needed, in particular to properly
> > link branches in our git tree, but it's doable,
> > and we have volunteers to do it.
> >
> > We'd like to hear about serious objections to the move, if any.
> >
> >
> >
> > *) normal - i

Re: [sagemath-admins] Fwd: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[John Cremona]

To me, as a contributor of code to Sage who has not contributed at all
to the backend support, it seems that there is a clear majority in
favour of moving to github.  As an ordinary developer I would be very
happy with that.

It looks to me as if Frédéric's main issue with github is his final
point "...We should rather not bow under the power of large
private companies.".  I don't know enough about gitlab to know if it
is a sensible alternative, but I myself have no problem with using
github for this, as I do for just about everything else.

John

On Fri, 9 Sept 2022 at 15:10, Thierry  wrote:
>
> Hi,
>
> let me forward the email of Frédéric as a whole, so that the thread remains
> complete.
>
> - Forwarded message from Frédéric Chapoton  -
>
> Date: Fri, 9 Sep 2022 12:15:25 +0200
> From: Frédéric Chapoton
> To: sagemath-adm...@googlegroups.com
> Subject: Re: [sagemath-admins] Fwd: [sage-devel] Re: incremental migration
> to github? [prompted by FUNDING issues!!!] + general flakiness of trac
>
> Dear sage developers and maintainers,
>
> Whereas I agree that we currently have two issues, I do not agree on the
> necessity to switch to github and certainly not urgently.
>
> * The first issue is the cost of google compute engine. This is under
> investigation and can be lowered by creating a new project. This should be
> do-able and could save us 3 $ per day.
> * The second issue is about new users entering new ssh keys. There is hope
> to fix that and in the mean-time one could ask new users to send sshkeys to
> some of us.
>
> My own preference would be to go on using trac, for some years, as this is
> serving us quite well. We should not change this for superficial and
> temporary reasons.
>
> The serious reasons that I see are : money and the futre of the trac
> software itself.
>
> In my opinion, money is the only serious issue, and I would like to see
> trac heberged by some university. There are already several services in
> France, so another country would be better. Germany ? Somebody must step
> forward.
>
> About the trac software, it now has a python3-compatible version, available
> on most linux distributions. We should aim to use that. Once done, the
> situation will be stable.
>
> As a side matter, it seems to me that gitlab is much more in the spirit of
> open source software. We should rather not bow under the power of large
> private companies.
>
> Frédéric
>
> -
>
>
>
> On Fri, Sep 09, 2022 at 12:15:13PM +0100, Dima Pasechnik wrote:
> > On Fri, Sep 9, 2022 at 11:15 AM Frédéric Chapoton  
> > wrote:
> > >
> > > Dear sage developers and maintainers,
> > >
> > > Whereas I agree that we currently have two issues, I do not agree on the 
> > > necessity to switch to github and certainly not urgently.
> >
> > it is a disaster that new people can't come aboard easily. It really is 
> > urgent.
> > A convoluted system to get new developers onboard and contributing is
> > a very bad omen for open-source projects, it really is.
> >
> > E.g. try to contribute to something like OpenBSD - I'd sure most
> > potentail contributors  run away screaming,
> > upon learning that they must use CVS and e-mail patches around for approval.
> >
> > >
> > > * The first issue is the cost of google compute engine. This is under 
> > > investigation and can be lowered by creating a new project. This should 
> > > be do-able and could save us 3 $ per day.
> >
> > but this is far from free, still, and hosting prices are to go with
> > the energy prices, up and up.
> > It's really spending money on a questionable luxury, instead of
> > something useful.
> >
> > > * The second issue is about new users entering new ssh keys. There is 
> > > hope to fix that and in the mean-time one could ask new users to send 
> > > sshkeys to some of us.
> > >
> > > My own preference would be to go on using trac, for some years, as this 
> > > is serving us quite well. We should not change this for superficial and 
> > > temporary reasons.
> >
> > the reasons are not supreficial, in particular, trac+gitolite software
> > is obsolete.
> > I cannot imagine a new project that would choose it as a platform.
> >
> > >
> > > The serious reasons that I see are : money and the futre of the trac 
> > > software itself.
> > >
> > > In my opinion, money is the only serious issue, and I would like to see 
> > > trac heberged by some university. There are already several services in 
> > > France, so another country would be better. Germany ? Somebody must step 
> > > forward.
> > >
> > > About the trac software, it now has a python3-compatible version, 
> > > available on most linux distributions. We should aim to use that. Once 
> > > done, the situation will be stable.
> >
> > Why do you think so? The bus factors of trac and gitolite software are
> > very, very small.
> > (https://en.wikipedia.org/wiki/Bus_factor)
> > As well as the bus factor for our trac instance.
> >
> > >
> > > As a side matter, it seems to me that gitlab is much more i

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[Matthias Koeppe]

On Friday, September 9, 2022 at 7:48:07 AM UTC-7 Thierry 
(sage-googlesucks@xxx) wrote:

> - wiki is academically hosted and works pretty well. 
> Fees to the Sage community: 0$ per year


Not really relevant for this thread, but: 
The wiki is dead. It has zero community and its only remaining purpose is 
to keep an archive of Sage days activities. 
https://trac.sagemath.org/ticket/33725


-- 
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/400ed79d-54da-4b3e-8b67-f5a5dbeeb7a0n%40googlegroups.com.

Re: [sagemath-admins] Fwd: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[Matthias Koeppe]

On Friday, September 9, 2022 at 7:48:01 AM UTC-7 wst...@gmail.com wrote:

> By not using GitHub we are losing many potential contributors to Sage. 
> GitHub is by far the most popular site for hosting of open source 
> projects, and potential Sage developers are likely to be familiar with 
> GitHub. Not using GitHub adds a huge barrier to entry for Sage 
> development.
>

Indeed.

Lowering these barriers is extremely important to keep the Sage project 
alive.


-- 
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/9f2a5237-c673-489f-a814-972f5339e848n%40googlegroups.com.

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[Matthias Koeppe]

Strong +1 on moving to GitHub as soon as possible. 

Very important to convert the complete Trac ticket history to GitHub 
issues/PRs.


On Friday, September 9, 2022 at 2:54:06 AM UTC-7 Dima Pasechnik wrote:

> I am resurrecting this thread, as in addition of trac continuing to eat up 
> funds (at a rate of over US$ 10 per day at the moment), it has gotten 
> increasingly broken. In particular, in the last 2 weeks no new developers 
> can really join the project, as there is no normal* way to add new ssh keys 
> into trac accounts, and it's not possible to push/pull with "new" github 
> ssh keys, i.e. keys that were not already "known" to trac, i.e. added to 
> the trac store of ssh keys before the last breakage happened.
>
> As far as funding is concerned, attempts to bring trac to a "free" hosting 
> stalled (see earlier messages in this thread).
>
> A further longer term issue is that trac software is basically on life 
> support, and it's only matter of time it will become totally obsolete. 
>
> Such a move will allow a considerable simplification of our devops, and 
> free up quite a bit of developer time
> to do interesting work rather than messing around with semi-obsolete stuff 
> such as trac, gitolite, etc. 
>
> Importantly, Volker, the release manager, is willing to proceed with the 
> move.
>
> Also, various Sage upstream (and downstream) projects have moved away from 
> trac to github, e.g. Cython, or away from another system to github, e.g. 
> CPython, GAP, jupyter, etc...
>
> There is a trac ticket to manage the proposed move, 
> https://trac.sagemath.org/ticket/30363 tentatively set for Sage 9.8.
>
> I've conducted few experiments with a tool to import trac sites to github: 
> https://github.com/svigerske/trac-to-github, which in particular allows 
> to import trac tickets as github issues; a result of running it on few 
> tickets
> may be inspected here: 
> https://github.com/dimpase/trac_to_gh/issues?q=is%3Aissue+is%3Aclosed
> (Here issues 1-10 correspond to trac tickets one to one :-))
> Further work on trac-to-github will be needed, in particular to properly 
> link branches in our git tree, but it's doable,
> and we have volunteers to do it.
>
> We'd like to hear about serious objections to the move, if any.  
>
>
>
> *) normal - i.e. using trac interface; we (probably) still have a way to 
> modify the repository of ssh keys used by trac manually.
>
> On Thursday, March 18, 2021 at 10:53:54 AM UTC Frédéric Chapoton wrote:
>
>> Erik, did you stop the Orsay runners for gitlab ? It seems that the 
>> docker build there for 9.3.b9 is stuck by lack of runners.
>>
>> https://gitlab.com/sagemath/sage/-/pipelines
>>
>> Frédéric
>>
>> Le jeudi 11 mars 2021 à 13:25:52 UTC+1, erik@gmail.com a écrit :
>>
>>> On Thu, Mar 11, 2021 at 1:20 PM E. Madison Bray  
>>> wrote: 
>>> > 
>>> > On Thu, Mar 11, 2021 at 12:52 PM Dima Pasechnik  
>>> wrote: 
>>> > > 
>>> > > On Thu, Mar 11, 2021 at 10:11 AM Dima Pasechnik  
>>> wrote: 
>>> > > > 
>>> > > > On Wed, Mar 10, 2021 at 4:00 PM E. Madison Bray <
>>> erik@gmail.com> wrote: 
>>> > > > > 
>>> > > > > On Tue, Jan 12, 2021 at 11:33 PM tobia...@gmx.de <
>>> tobia...@gmx.de> wrote: 
>>> > > > > > 
>>> > > > > > 
>>> > > > > > For what's worth, + 1 for migrating to github. 
>>> > > > > > 
>>> > > > > > The interface is cleaner, it has many more features and 
>>> integrations, and is more active which could attract more contributions. 
>>> There are a few scripts/tools that allow to migrate from trac to github. 
>>> But most of them are unmaintained for a few years already, so I'm not sure 
>>> if they still work (which should be taken as a sign that one should migrate 
>>> sooner than later). 
>>> > > > > 
>>> > > > > In 2019 Julian Rüth and I, with the help of some others, already 
>>> put 
>>> > > > > in some effort to set up an organization for SageMath on GitLab: 
>>> > > > > https://gitlab.com/sagemath 
>>> > > > > 
>>> > > > > Between GitHub and GitLab, we felt that the latter would be more 
>>> > > > > acceptable to the broader Sage community. We also implemented a 
>>> bot 
>>> > > > > that can mirror GitLab merge requests as Trac tickets, though 
>>> it's 
>>> > > > > been in need of troubleshooting for a while. 
>>> > > > > 
>>> > > > > This was also done before the advent of GitHub Actions, and the 
>>> > > > > ability to provide custom CI runners for GitLab Pipelines seemed 
>>> > > > > advantageous, since we could maintain our own fleet of runners, 
>>> be it 
>>> > > > > on Sage developers' personal machines (if they are generous 
>>> enough to 
>>> > > > > host them) or any conceivable constellation of cloud computing 
>>> > > > > platforms. 
>>> > > > > 
>>> > > > > In practice this has gained little traction, in part due to lack 
>>> of 
>>> > > > > advertising. The GitLab Runner solution also proved a bit 
>>> troublesome 
>>> > > > > to maintain, as it required some constant attention to make sure 
>>> there 
>>> > > > > were always 

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[Thierry]

Hi,

"[prompted by FUNDING issues!!!]" ???

Back in 2016, when cloud hosting was imposed over academic hosting,
William promised "to pay for it indefinitely", see
https://groups.google.com/g/sage-devel/c/ed_ya-d-k_E/m/jYoR6opODAAJ

If only for this reason, there is no funding issue.

The fact is that the the magic cloud ideology turned into a disaster,
years after years, from askbot in 2014 (thanks again to Niles and OSU
sysadmins for their involvement in its academic hosting during six
years !), to the wiki a few months ago, and now trac+git.

I have been involved in rescuing those services, and putting them back
in a safe place. What do the facts tell us about academic hosting, in
2022 ?

- askbot is academically hosted and works pretty well.
  Fees to the Sage community: 0$ per year

- patchbot server is academically hosted and works pretty well.
  Fees to the Sage community: 0$ per year

- I bet that most patchbot clients are run from academic desktops.
  Fees to the Sage community: 0$ per year

- wiki is academically hosted and works pretty well.
  Fees to the Sage community: 0$ per year

- the backup server (which currently backs up askbot and wiki) is 
  academically hosted and works pretty well.
  Fees to the Sage community: 0$ per year

- most download mirrors are academically hosted and work pretty well.
  Fees to the Sage community: 0$ per year

For this reason also, and given the number of universities around the
world, there is no funding issue. The rest is FUD.

Ciao,
Thierry



On Fri, Sep 09, 2022 at 02:54:06AM -0700, Dima Pasechnik wrote:
> I am resurrecting this thread, as in addition of trac continuing to eat up 
> funds (at a rate of over US$ 10 per day at the moment), it has gotten 
> increasingly broken. In particular, in the last 2 weeks no new developers 
> can really join the project, as there is no normal* way to add new ssh keys 
> into trac accounts, and it's not possible to push/pull with "new" github 
> ssh keys, i.e. keys that were not already "known" to trac, i.e. added to 
> the trac store of ssh keys before the last breakage happened.
> 
> As far as funding is concerned, attempts to bring trac to a "free" hosting 
> stalled (see earlier messages in this thread).
> 
> A further longer term issue is that trac software is basically on life 
> support, and it's only matter of time it will become totally obsolete. 
> 
> Such a move will allow a considerable simplification of our devops, and 
> free up quite a bit of developer time
> to do interesting work rather than messing around with semi-obsolete stuff 
> such as trac, gitolite, etc. 
> 
> Importantly, Volker, the release manager, is willing to proceed with the 
> move.
> 
> Also, various Sage upstream (and downstream) projects have moved away from 
> trac to github, e.g. Cython, or away from another system to github, e.g. 
> CPython, GAP, jupyter, etc...
> 
> There is a trac ticket to manage the proposed move, 
> https://trac.sagemath.org/ticket/30363 tentatively set for Sage 9.8.
> 
> I've conducted few experiments with a tool to import trac sites to 
> github: https://github.com/svigerske/trac-to-github, which in particular 
> allows to import trac tickets as github issues; a result of running it on 
> few tickets
> may be inspected 
> here: https://github.com/dimpase/trac_to_gh/issues?q=is%3Aissue+is%3Aclosed
> (Here issues 1-10 correspond to trac tickets one to one :-))
> Further work on trac-to-github will be needed, in particular to properly 
> link branches in our git tree, but it's doable,
> and we have volunteers to do it.
> 
> We'd like to hear about serious objections to the move, if any.  
> 
> 
> 
> *) normal - i.e. using trac interface; we (probably) still have a way to 
> modify the repository of ssh keys used by trac manually.
> 
> On Thursday, March 18, 2021 at 10:53:54 AM UTC Frédéric Chapoton wrote:
> 
> > Erik, did you stop the Orsay runners for gitlab ? It seems that the docker 
> > build there for 9.3.b9 is stuck by lack of runners.
> >
> > https://gitlab.com/sagemath/sage/-/pipelines
> >
> > Frédéric
> >
> > Le jeudi 11 mars 2021 à 13:25:52 UTC+1, erik@gmail.com a écrit :
> >
> >> On Thu, Mar 11, 2021 at 1:20 PM E. Madison Bray  
> >> wrote: 
> >> > 
> >> > On Thu, Mar 11, 2021 at 12:52 PM Dima Pasechnik  
> >> wrote: 
> >> > > 
> >> > > On Thu, Mar 11, 2021 at 10:11 AM Dima Pasechnik  
> >> wrote: 
> >> > > > 
> >> > > > On Wed, Mar 10, 2021 at 4:00 PM E. Madison Bray  
> >> wrote: 
> >> > > > > 
> >> > > > > On Tue, Jan 12, 2021 at 11:33 PM tobia...@gmx.de  
> >> wrote: 
> >> > > > > > 
> >> > > > > > 
> >> > > > > > For what's worth, + 1 for migrating to github. 
> >> > > > > > 
> >> > > > > > The interface is cleaner, it has many more features and 
> >> integrations, and is more active which could attract more contributions. 
> >> There are a few scripts/tools that allow to migrate from trac to github. 
> >> But most of them are unmaintained for a few years already, so I'm not sure 
> >> if t

Re: [sagemath-admins] Fwd: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[William Stein]

Hi,

By not using GitHub we are losing many potential contributors to Sage.
GitHub is by far the most popular site for hosting of open source
projects, and potential Sage developers are likely to be familiar with
GitHub.  Not using GitHub adds a huge barrier to entry for Sage
development.

For example, I don't contribute to Sage anymore because the barrier to
entry via trac is too high.  I contributed (and had accepted) a little
pull request yesterday to numpy **because** the barrier was so low.

 -- William

On Fri, Sep 9, 2022 at 7:40 AM Dima Pasechnik  wrote:
>
>
>
> On Fri, 9 Sep 2022, 15:26 Kwankyu Lee,  wrote:
>>
>>
>>> the futre of the trac software itself.
>>
>>
>> According to their developer mailing list
>>
>> https://groups.google.com/g/trac-dev
>>
>> the future of trac seems not so ominous to me.
>
>
> 18 posts (in half a dozen threads) since beginning of 2022 does not look 
> healthy to me.
>
> And on their users group one sees that it's populated by people who have 
> projects running SVN and  mercurial - VCSs not supported by GitHub.
>
>
>>
>> Perhaps publishing our fork of trac with customized plugins (?) to sagemath 
>> github repo may help increase  the bus factor about our own trac
>
>
> maintaining our trac does not bring me (or anyone, I suppose) any joy.
>
> If your objection to the move is strong - you are welcome to take over.
>
> Fred, Jan, and me spent together perhaps 40 working hours on this totally 
> thankless task in the last 2 weeks. We could instead have done something 
> useful for Sage proper instead.
>
>>
>>
>>
>> --
>> 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/c5050c0a-3bcb-4f01-af40-ff3e7a8cb393n%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/CAAWYfq3jS%2B--h_DUyDk5WAZkiXVy_zLKbiPk9dUhnrqtKNSP6A%40mail.gmail.com.



-- 
William (http://wstein.org)

-- 
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/CACLE5GAbJ0%3DU%3DFyN%3DfJPkT88mfrAdHHCtsgedbZ%3DcipOwKV8Vw%40mail.gmail.com.

Re: [sagemath-admins] Fwd: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[Dima Pasechnik]

On Fri, 9 Sep 2022, 15:26 Kwankyu Lee,  wrote:

>
> the futre of the trac software itself.
>>
>
> According to their developer mailing list
>
> https://groups.google.com/g/trac-dev
>
> the future of trac seems not so ominous to me.
>

18 posts (in half a dozen threads) since beginning of 2022 does not look
healthy to me.

And on their users group one sees that it's populated by people who have
projects running SVN and  mercurial - VCSs not supported by GitHub.



> Perhaps publishing our fork of trac with customized plugins (?) to
> sagemath github repo may help increase  the bus factor about our own trac
>

maintaining our trac does not bring me (or anyone, I suppose) any joy.

If your objection to the move is strong - you are welcome to take over.

Fred, Jan, and me spent together perhaps 40 working hours on this totally
thankless task in the last 2 weeks. We could instead have done something
useful for Sage proper instead.


>
>
> --
> 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/c5050c0a-3bcb-4f01-af40-ff3e7a8cb393n%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/CAAWYfq3jS%2B--h_DUyDk5WAZkiXVy_zLKbiPk9dUhnrqtKNSP6A%40mail.gmail.com.

Re: [sagemath-admins] Fwd: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[Kwankyu Lee]

> the futre of the trac software itself.
>

According to their developer mailing list

https://groups.google.com/g/trac-dev

the future of trac seems not so ominous to me.

Perhaps publishing our fork of trac with customized plugins (?) to sagemath 
github repo may help increase  the bus factor about our own 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/c5050c0a-3bcb-4f01-af40-ff3e7a8cb393n%40googlegroups.com.

[sage-devel] BROADCAST : Trac maintenance

[Frédéric Chapoton]

Dear Sage developers,

in order to try to fix better the recent upgrade, the *trac web server will 
be turned off this saturday 10/09/2022*, from 7.00 (Paris time) to 23:00 
(Paris time ; https://time.is/Paris).

PLEASE take again a short break and resume using trac next week!

Sorry for the inconvience, and thanks for your patience. We are getting 
close.

Frédéric

-- 
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/79031119-f0bd-49bd-a36e-846b01e819d1n%40googlegroups.com.

Re: [sagemath-admins] Fwd: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[Thierry]

Hi,

let me forward the email of Frédéric as a whole, so that the thread remains
complete.

- Forwarded message from Frédéric Chapoton  -

Date: Fri, 9 Sep 2022 12:15:25 +0200
From: Frédéric Chapoton
To: sagemath-adm...@googlegroups.com
Subject: Re: [sagemath-admins] Fwd: [sage-devel] Re: incremental migration
to github? [prompted by FUNDING issues!!!] + general flakiness of trac

Dear sage developers and maintainers,

Whereas I agree that we currently have two issues, I do not agree on the
necessity to switch to github and certainly not urgently.

* The first issue is the cost of google compute engine. This is under
investigation and can be lowered by creating a new project. This should be
do-able and could save us 3 $ per day.
* The second issue is about new users entering new ssh keys. There is hope
to fix that and in the mean-time one could ask new users to send sshkeys to
some of us.

My own preference would be to go on using trac, for some years, as this is
serving us quite well. We should not change this for superficial and
temporary reasons.

The serious reasons that I see are : money and the futre of the trac
software itself.

In my opinion, money is the only serious issue, and I would like to see
trac heberged by some university. There are already several services in
France, so another country would be better. Germany ? Somebody must step
forward.

About the trac software, it now has a python3-compatible version, available
on most linux distributions. We should aim to use that. Once done, the
situation will be stable.

As a side matter, it seems to me that gitlab is much more in the spirit of
open source software. We should rather not bow under the power of large
private companies.

Frédéric

-



On Fri, Sep 09, 2022 at 12:15:13PM +0100, Dima Pasechnik wrote:
> On Fri, Sep 9, 2022 at 11:15 AM Frédéric Chapoton  
> wrote:
> >
> > Dear sage developers and maintainers,
> >
> > Whereas I agree that we currently have two issues, I do not agree on the 
> > necessity to switch to github and certainly not urgently.
> 
> it is a disaster that new people can't come aboard easily. It really is 
> urgent.
> A convoluted system to get new developers onboard and contributing is
> a very bad omen for open-source projects, it really is.
> 
> E.g. try to contribute to something like OpenBSD - I'd sure most
> potentail contributors  run away screaming,
> upon learning that they must use CVS and e-mail patches around for approval.
> 
> >
> > * The first issue is the cost of google compute engine. This is under 
> > investigation and can be lowered by creating a new project. This should be 
> > do-able and could save us 3 $ per day.
> 
> but this is far from free, still, and hosting prices are to go with
> the energy prices, up and up.
> It's really spending money on a questionable luxury, instead of
> something useful.
> 
> > * The second issue is about new users entering new ssh keys. There is hope 
> > to fix that and in the mean-time one could ask new users to send sshkeys to 
> > some of us.
> >
> > My own preference would be to go on using trac, for some years, as this is 
> > serving us quite well. We should not change this for superficial and 
> > temporary reasons.
> 
> the reasons are not supreficial, in particular, trac+gitolite software
> is obsolete.
> I cannot imagine a new project that would choose it as a platform.
> 
> >
> > The serious reasons that I see are : money and the futre of the trac 
> > software itself.
> >
> > In my opinion, money is the only serious issue, and I would like to see 
> > trac heberged by some university. There are already several services in 
> > France, so another country would be better. Germany ? Somebody must step 
> > forward.
> >
> > About the trac software, it now has a python3-compatible version, available 
> > on most linux distributions. We should aim to use that. Once done, the 
> > situation will be stable.
> 
> Why do you think so? The bus factors of trac and gitolite software are
> very, very small.
> (https://en.wikipedia.org/wiki/Bus_factor)
> As well as the bus factor for our trac instance.
> 
> >
> > As a side matter, it seems to me that gitlab is much more in the spirit of 
> > open source software. We should rather not bow under the power of large 
> > private companies.
> Let's not get into this argument. I don't see how paying Google's
> adware criminals US$4000 per year is more ethical than moving over to
> GitHub (which, by the way, gives us a bit of money,
> via GitHub sponsors system :-)).
> Besides, moving from GitHub to GitLab is rather easy, compared to move
> from trac to Git**b.
> 
> Dima
> 
> 
> 
> 
> >
> > Frédéric
> >
> >
> > Le ven. 9 sept. 2022 à 11:55, Dima Pasechnik  a écrit :
> >>
> >> -- Forwarded message -
> >> From: Dima Pasechnik 
> >> Date: Fri, Sep 9, 2022 at 10:54 AM
> >> Subject: Re: [sage-devel] Re: incremental migration to github?
> >> [prompted by FUNDING issues!!!] + general flakiness of trac
>

Re: [sagemath-admins] Fwd: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[Dima Pasechnik]

On Fri, Sep 9, 2022 at 11:15 AM Frédéric Chapoton  wrote:
>
> Dear sage developers and maintainers,
>
> Whereas I agree that we currently have two issues, I do not agree on the 
> necessity to switch to github and certainly not urgently.

it is a disaster that new people can't come aboard easily. It really is urgent.
A convoluted system to get new developers onboard and contributing is
a very bad omen for open-source projects, it really is.

E.g. try to contribute to something like OpenBSD - I'd sure most
potentail contributors  run away screaming,
upon learning that they must use CVS and e-mail patches around for approval.

>
> * The first issue is the cost of google compute engine. This is under 
> investigation and can be lowered by creating a new project. This should be 
> do-able and could save us 3 $ per day.

but this is far from free, still, and hosting prices are to go with
the energy prices, up and up.
It's really spending money on a questionable luxury, instead of
something useful.

> * The second issue is about new users entering new ssh keys. There is hope to 
> fix that and in the mean-time one could ask new users to send sshkeys to some 
> of us.
>
> My own preference would be to go on using trac, for some years, as this is 
> serving us quite well. We should not change this for superficial and 
> temporary reasons.

the reasons are not supreficial, in particular, trac+gitolite software
is obsolete.
I cannot imagine a new project that would choose it as a platform.

>
> The serious reasons that I see are : money and the futre of the trac software 
> itself.
>
> In my opinion, money is the only serious issue, and I would like to see trac 
> heberged by some university. There are already several services in France, so 
> another country would be better. Germany ? Somebody must step forward.
>
> About the trac software, it now has a python3-compatible version, available 
> on most linux distributions. We should aim to use that. Once done, the 
> situation will be stable.

Why do you think so? The bus factors of trac and gitolite software are
very, very small.
(https://en.wikipedia.org/wiki/Bus_factor)
As well as the bus factor for our trac instance.

>
> As a side matter, it seems to me that gitlab is much more in the spirit of 
> open source software. We should rather not bow under the power of large 
> private companies.
Let's not get into this argument. I don't see how paying Google's
adware criminals US$4000 per year is more ethical than moving over to
GitHub (which, by the way, gives us a bit of money,
via GitHub sponsors system :-)).
Besides, moving from GitHub to GitLab is rather easy, compared to move
from trac to Git**b.

Dima




>
> Frédéric
>
>
> Le ven. 9 sept. 2022 à 11:55, Dima Pasechnik  a écrit :
>>
>> -- Forwarded message -
>> From: Dima Pasechnik 
>> Date: Fri, Sep 9, 2022 at 10:54 AM
>> Subject: Re: [sage-devel] Re: incremental migration to github?
>> [prompted by FUNDING issues!!!] + general flakiness of trac
>> To: sage-devel 
>>
>>
>> I am resurrecting this thread, as in addition of trac continuing to
>> eat up funds (at a rate of over US$ 10 per day at the moment), it has
>> gotten increasingly broken. In particular, in the last 2 weeks no new
>> developers can really join the project, as there is no normal* way to
>> add new ssh keys into trac accounts, and it's not possible to
>> push/pull with "new" github ssh keys, i.e. keys that were not already
>> "known" to trac, i.e. added to the trac store of ssh keys before the
>> last breakage happened.
>>
>> As far as funding is concerned, attempts to bring trac to a "free"
>> hosting stalled (see earlier messages in this thread).
>>
>> A further longer term issue is that trac software is basically on life
>> support, and it's only matter of time it will become totally obsolete.
>>
>> Such a move will allow a considerable simplification of our devops,
>> and free up quite a bit of developer time
>> to do interesting work rather than messing around with semi-obsolete
>> stuff such as trac, gitolite, etc.
>>
>> Importantly, Volker, the release manager, is willing to proceed with the 
>> move.
>>
>> Also, various Sage upstream (and downstream) projects have moved away
>> from trac to github, e.g. Cython, or away from another system to
>> github, e.g. CPython, GAP, jupyter, etc...
>>
>> There is a trac ticket to manage the proposed move,
>> https://trac.sagemath.org/ticket/30363 tentatively set for Sage 9.8.
>>
>> I've conducted few experiments with a tool to import trac sites to
>> github: https://github.com/svigerske/trac-to-github, which in
>> particular allows to import trac tickets as github issues; a result of
>> running it on few tickets
>> may be inspected here:
>> https://github.com/dimpase/trac_to_gh/issues?q=is%3Aissue+is%3Aclosed
>> (Here issues 1-10 correspond to trac tickets one to one :-))
>> Further work on trac-to-github will be needed, in particular to
>> properly link branches in our git tree, b

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[Dima Pasechnik]

I am resurrecting this thread, as in addition of trac continuing to eat up 
funds (at a rate of over US$ 10 per day at the moment), it has gotten 
increasingly broken. In particular, in the last 2 weeks no new developers 
can really join the project, as there is no normal* way to add new ssh keys 
into trac accounts, and it's not possible to push/pull with "new" github 
ssh keys, i.e. keys that were not already "known" to trac, i.e. added to 
the trac store of ssh keys before the last breakage happened.

As far as funding is concerned, attempts to bring trac to a "free" hosting 
stalled (see earlier messages in this thread).

A further longer term issue is that trac software is basically on life 
support, and it's only matter of time it will become totally obsolete. 

Such a move will allow a considerable simplification of our devops, and 
free up quite a bit of developer time
to do interesting work rather than messing around with semi-obsolete stuff 
such as trac, gitolite, etc. 

Importantly, Volker, the release manager, is willing to proceed with the 
move.

Also, various Sage upstream (and downstream) projects have moved away from 
trac to github, e.g. Cython, or away from another system to github, e.g. 
CPython, GAP, jupyter, etc...

There is a trac ticket to manage the proposed move, 
https://trac.sagemath.org/ticket/30363 tentatively set for Sage 9.8.

I've conducted few experiments with a tool to import trac sites to 
github: https://github.com/svigerske/trac-to-github, which in particular 
allows to import trac tickets as github issues; a result of running it on 
few tickets
may be inspected 
here: https://github.com/dimpase/trac_to_gh/issues?q=is%3Aissue+is%3Aclosed
(Here issues 1-10 correspond to trac tickets one to one :-))
Further work on trac-to-github will be needed, in particular to properly 
link branches in our git tree, but it's doable,
and we have volunteers to do it.

We'd like to hear about serious objections to the move, if any.  



*) normal - i.e. using trac interface; we (probably) still have a way to 
modify the repository of ssh keys used by trac manually.

On Thursday, March 18, 2021 at 10:53:54 AM UTC Frédéric Chapoton wrote:

> Erik, did you stop the Orsay runners for gitlab ? It seems that the docker 
> build there for 9.3.b9 is stuck by lack of runners.
>
> https://gitlab.com/sagemath/sage/-/pipelines
>
> Frédéric
>
> Le jeudi 11 mars 2021 à 13:25:52 UTC+1, erik@gmail.com a écrit :
>
>> On Thu, Mar 11, 2021 at 1:20 PM E. Madison Bray  
>> wrote: 
>> > 
>> > On Thu, Mar 11, 2021 at 12:52 PM Dima Pasechnik  
>> wrote: 
>> > > 
>> > > On Thu, Mar 11, 2021 at 10:11 AM Dima Pasechnik  
>> wrote: 
>> > > > 
>> > > > On Wed, Mar 10, 2021 at 4:00 PM E. Madison Bray  
>> wrote: 
>> > > > > 
>> > > > > On Tue, Jan 12, 2021 at 11:33 PM tobia...@gmx.de  
>> wrote: 
>> > > > > > 
>> > > > > > 
>> > > > > > For what's worth, + 1 for migrating to github. 
>> > > > > > 
>> > > > > > The interface is cleaner, it has many more features and 
>> integrations, and is more active which could attract more contributions. 
>> There are a few scripts/tools that allow to migrate from trac to github. 
>> But most of them are unmaintained for a few years already, so I'm not sure 
>> if they still work (which should be taken as a sign that one should migrate 
>> sooner than later). 
>> > > > > 
>> > > > > In 2019 Julian Rüth and I, with the help of some others, already 
>> put 
>> > > > > in some effort to set up an organization for SageMath on GitLab: 
>> > > > > https://gitlab.com/sagemath 
>> > > > > 
>> > > > > Between GitHub and GitLab, we felt that the latter would be more 
>> > > > > acceptable to the broader Sage community. We also implemented a 
>> bot 
>> > > > > that can mirror GitLab merge requests as Trac tickets, though 
>> it's 
>> > > > > been in need of troubleshooting for a while. 
>> > > > > 
>> > > > > This was also done before the advent of GitHub Actions, and the 
>> > > > > ability to provide custom CI runners for GitLab Pipelines seemed 
>> > > > > advantageous, since we could maintain our own fleet of runners, 
>> be it 
>> > > > > on Sage developers' personal machines (if they are generous 
>> enough to 
>> > > > > host them) or any conceivable constellation of cloud computing 
>> > > > > platforms. 
>> > > > > 
>> > > > > In practice this has gained little traction, in part due to lack 
>> of 
>> > > > > advertising. The GitLab Runner solution also proved a bit 
>> troublesome 
>> > > > > to maintain, as it required some constant attention to make sure 
>> there 
>> > > > > were always working runners available. I tried to keep that up 
>> for a 
>> > > > > while myself, but have had other obligations. 
>> > > > 
>> > > > I think it should be mentioned that GitLab has an analog of GitHub 
>> Actions, 
>> > > > and the difference is that its runners may be self-hosted, or 
>> provided 
>> > > > by GitLab. 
>> > > > E.g. see https://gitlab.com/sagemath/dev/trac/-/pipelines/

[sage-devel] Bug in decomposition_type

[Björn Selander]

Hi, 

running the Sage script 

K. = NumberField(x^4 + 18*x^2 - 1)
R. = K[]
L. = K.extension(y^2 + 9*a^3 - 2*a^2 + 162*a - 38)

dt = [L.decomposition_type(i) for i in K.primes_above(3)]
print(dt)

gives the output

[[(1, 1, 2)], [(1, 1, 2)], [(1, 1, 1)]]

The third element in the list ought to be nonsense. Certainly the products 
of the entries of all sublists should be 2. 

Regards
Björn

-- 
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/a875cd6e-37ec-49e3-a85a-b84b33b37983n%40googlegroups.com.

[sage-devel] docstring of _element_constructor_

['Martin R' via sage-devel]

Dear all,

as a user, how am I supposed to access the docstring of an 
_element_constructor_?

For example,

sage: P. = QQ[]
sage: P?

does not give me any hint about the various ways to construct a polynomial.

If this is not possible other than "R._element_constructor_?", then, as 
developers, how should we make this documentation accessible?

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