Re: [sage-devel] Re: Package installation/uninstallation confusion
On Wed, Nov 6, 2019 at 7:17 PM John H Palmieri wrote:
>
> Simon, you should look at the json file for p_group_cohomology to see if it
> contains all of the installed files, or if indeed some are not listed. If
> everything is there, there is no need to split it into two packages, unless
> I'm missing something.
if you look at its spkg-install, you'd see that shd_install is not
used at some place, instead
make install
is done, something that won't write any JSON files, IMHO...
>
>
>
> On Wednesday, November 6, 2019 at 9:33:04 AM UTC-8, Dima Pasechnik wrote:
>>
>> sdh_install installs a json file into
>> SAGE_LOCAL/var/lib/sage/installed/
>> which are then used by unistallaller
>>
>> e.g. "make meataxe" produces SAGE_LOCAL/var/lib/sage/installed/meataxe-1.0.p0
>> {
>> "package_name": "meataxe",
>> "package_version": "1.0.p0",
>> "install_date": "Wed Nov 6 17:24:57 GMT 2019",
>> "system_uname": "Linux hilbert 5.1.12-gentoo #1 SMP Fri Jun 21
>> 19:27:38 BST 2019 x86_64 Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz
>> GenuineIntel GNU/Linux",
>> "sage_version": "SageMath version 9.0.beta4, Release Date: 2019-11-02",
>> "test_result": "",
>> "files": [
>> "bin/cfcomp",
>> "bin/chop",
>> ...
>> }
>>
>> I guess sdh_pip_install does not do this, I don't know.
>>
>> Anyhow, it would make perfect sense to split the package into two, as
>> you propose.
>>
>> On Wed, Nov 6, 2019 at 3:55 PM Simon King wrote:
>> >
>> > Hi Eric,
>> >
>> > On 2019-11-06, E. Madison Bray wrote:
>> > >> However, I heard rumours that in order to make a Sage optional package
>> > >> uninstallable, one needs some new script analogous to spkg-install.
>> > >>
>> > >> Can someone give me a pointer on what should be done in that script and
>> > >> what tools (sdh_*) are available for it?
>> > >
>> > > That's not quite accurate. In general you do *not* need any
>> > > additional scripts, with some exception.
>> > > These packaging guidelines still need better documentation, but
>> > > essentially you need to make sure the package is built for what is
>> > > referred in GNU standards as a "DESTDIR install" [1]. This means that
>> > > the package is built for installation to some particular prefix (e.g.
>> > > `./configure --prefix=$SAGE_LOCAL` in autoconf terms), but can then be
>> > > *installed* with some additional path (the "DESTDIR") prepended to the
>> > > prefix. This is similar to providing an alternate root (e.g. prefix
>> > > is appended to DESTDIR instead of just "/").
>> >
>> > Then what to do with p_group_cohomology? Its spkg-install script
>> > installs two sub-packages. Each of them, I think, follows the above
>> > scheme. However, Sage has no way of knowing that uninstalling
>> > p_group_cohomology means uninstalling two sub-packages.
>> >
>> > Perhaps one possibility is to split the current p_group_cohomology-3.3
>> > into its two sub-packages, and make the first (which is autotoolized)
>> > a dependency for the second (which is a bunch of cython and python
>> > modules linked against the first sub-package.
>> >
>> > Say:
>> > - p_group_cohomology-3.4 shall only comprise what currently is the
>> > p/cython part of p_group_cohomology-3.3, and have modular_resolution
>> > as a dependency.
>> > - modular_resolution-1.0 shall only comprise what currently is the
>> > autotoolized c-library part of p_group_cohomology-3.3
>> >
>> > Advantage: "make p_group_cohomology" would also install the dependency,
>> > hence, both packages get installed. And both packages can also be
>> > un-installed, I suppose.
>> >
>> > Disadvantage: The only purpose of modular_resolution-1.0 would be to
>> > serve as a dependency, it is (to my knowledge at least) of no
>> > independent use.
>> >
>> > Best regards,
>> > Simon
>> >
>> > --
>> > 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-...@googlegroups.com.
>> > To view this discussion on the web visit
>> > https://groups.google.com/d/msgid/sage-devel/qpuqe5%247598%241%40blaine.gmane.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/f30617cc-9e63-49b2-b097-b10682596c1b%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/CAAWYfq3R-vdqXwBo9j5EvZJ%2BBMFycwrzGs7QQBpiM5JuGAbkew%40mail.gmail.com.
Re: [sage-devel] Re: Package installation/uninstallation confusion
Simon, you should look at the json file for p_group_cohomology to see if it
contains all of the installed files, or if indeed some are not listed. If
everything is there, there is no need to split it into two packages, unless
I'm missing something.
On Wednesday, November 6, 2019 at 9:33:04 AM UTC-8, Dima Pasechnik wrote:
>
> sdh_install installs a json file into
> SAGE_LOCAL/var/lib/sage/installed/
> which are then used by unistallaller
>
> e.g. "make meataxe" produces
> SAGE_LOCAL/var/lib/sage/installed/meataxe-1.0.p0
> {
> "package_name": "meataxe",
> "package_version": "1.0.p0",
> "install_date": "Wed Nov 6 17:24:57 GMT 2019",
> "system_uname": "Linux hilbert 5.1.12-gentoo #1 SMP Fri Jun 21
> 19:27:38 BST 2019 x86_64 Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz
> GenuineIntel GNU/Linux",
> "sage_version": "SageMath version 9.0.beta4, Release Date:
> 2019-11-02",
> "test_result": "",
> "files": [
> "bin/cfcomp",
> "bin/chop",
> ...
> }
>
> I guess sdh_pip_install does not do this, I don't know.
>
> Anyhow, it would make perfect sense to split the package into two, as
> you propose.
>
> On Wed, Nov 6, 2019 at 3:55 PM Simon King > wrote:
> >
> > Hi Eric,
> >
> > On 2019-11-06, E. Madison Bray > wrote:
> > >> However, I heard rumours that in order to make a Sage optional
> package
> > >> uninstallable, one needs some new script analogous to spkg-install.
> > >>
> > >> Can someone give me a pointer on what should be done in that script
> and
> > >> what tools (sdh_*) are available for it?
> > >
> > > That's not quite accurate. In general you do *not* need any
> > > additional scripts, with some exception.
> > > These packaging guidelines still need better documentation, but
> > > essentially you need to make sure the package is built for what is
> > > referred in GNU standards as a "DESTDIR install" [1]. This means that
> > > the package is built for installation to some particular prefix (e.g.
> > > `./configure --prefix=$SAGE_LOCAL` in autoconf terms), but can then be
> > > *installed* with some additional path (the "DESTDIR") prepended to the
> > > prefix. This is similar to providing an alternate root (e.g. prefix
> > > is appended to DESTDIR instead of just "/").
> >
> > Then what to do with p_group_cohomology? Its spkg-install script
> > installs two sub-packages. Each of them, I think, follows the above
> > scheme. However, Sage has no way of knowing that uninstalling
> > p_group_cohomology means uninstalling two sub-packages.
> >
> > Perhaps one possibility is to split the current p_group_cohomology-3.3
> > into its two sub-packages, and make the first (which is autotoolized)
> > a dependency for the second (which is a bunch of cython and python
> > modules linked against the first sub-package.
> >
> > Say:
> > - p_group_cohomology-3.4 shall only comprise what currently is the
> > p/cython part of p_group_cohomology-3.3, and have modular_resolution
> > as a dependency.
> > - modular_resolution-1.0 shall only comprise what currently is the
> > autotoolized c-library part of p_group_cohomology-3.3
> >
> > Advantage: "make p_group_cohomology" would also install the dependency,
> > hence, both packages get installed. And both packages can also be
> > un-installed, I suppose.
> >
> > Disadvantage: The only purpose of modular_resolution-1.0 would be to
> > serve as a dependency, it is (to my knowledge at least) of no
> > independent use.
> >
> > Best regards,
> > Simon
> >
> > --
> > 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-...@googlegroups.com .
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-devel/qpuqe5%247598%241%40blaine.gmane.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/f30617cc-9e63-49b2-b097-b10682596c1b%40googlegroups.com.
Re: [sage-devel] Re: Package installation/uninstallation confusion
sdh_install installs a json file into
SAGE_LOCAL/var/lib/sage/installed/
which are then used by unistallaller
e.g. "make meataxe" produces SAGE_LOCAL/var/lib/sage/installed/meataxe-1.0.p0
{
"package_name": "meataxe",
"package_version": "1.0.p0",
"install_date": "Wed Nov 6 17:24:57 GMT 2019",
"system_uname": "Linux hilbert 5.1.12-gentoo #1 SMP Fri Jun 21
19:27:38 BST 2019 x86_64 Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz
GenuineIntel GNU/Linux",
"sage_version": "SageMath version 9.0.beta4, Release Date: 2019-11-02",
"test_result": "",
"files": [
"bin/cfcomp",
"bin/chop",
...
}
I guess sdh_pip_install does not do this, I don't know.
Anyhow, it would make perfect sense to split the package into two, as
you propose.
On Wed, Nov 6, 2019 at 3:55 PM Simon King wrote:
>
> Hi Eric,
>
> On 2019-11-06, E. Madison Bray wrote:
> >> However, I heard rumours that in order to make a Sage optional package
> >> uninstallable, one needs some new script analogous to spkg-install.
> >>
> >> Can someone give me a pointer on what should be done in that script and
> >> what tools (sdh_*) are available for it?
> >
> > That's not quite accurate. In general you do *not* need any
> > additional scripts, with some exception.
> > These packaging guidelines still need better documentation, but
> > essentially you need to make sure the package is built for what is
> > referred in GNU standards as a "DESTDIR install" [1]. This means that
> > the package is built for installation to some particular prefix (e.g.
> > `./configure --prefix=$SAGE_LOCAL` in autoconf terms), but can then be
> > *installed* with some additional path (the "DESTDIR") prepended to the
> > prefix. This is similar to providing an alternate root (e.g. prefix
> > is appended to DESTDIR instead of just "/").
>
> Then what to do with p_group_cohomology? Its spkg-install script
> installs two sub-packages. Each of them, I think, follows the above
> scheme. However, Sage has no way of knowing that uninstalling
> p_group_cohomology means uninstalling two sub-packages.
>
> Perhaps one possibility is to split the current p_group_cohomology-3.3
> into its two sub-packages, and make the first (which is autotoolized)
> a dependency for the second (which is a bunch of cython and python
> modules linked against the first sub-package.
>
> Say:
> - p_group_cohomology-3.4 shall only comprise what currently is the
> p/cython part of p_group_cohomology-3.3, and have modular_resolution
> as a dependency.
> - modular_resolution-1.0 shall only comprise what currently is the
> autotoolized c-library part of p_group_cohomology-3.3
>
> Advantage: "make p_group_cohomology" would also install the dependency,
> hence, both packages get installed. And both packages can also be
> un-installed, I suppose.
>
> Disadvantage: The only purpose of modular_resolution-1.0 would be to
> serve as a dependency, it is (to my knowledge at least) of no
> independent use.
>
> Best regards,
> Simon
>
> --
> 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/qpuqe5%247598%241%40blaine.gmane.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/CAAWYfq22%3DK%2Bss9jhCj2L57iBOe5i9_5iUE9Kdg-ZQO_SxwM50Q%40mail.gmail.com.
[sage-devel] Re: Package installation/uninstallation confusion
Hi Eric, On 2019-11-06, E. Madison Bray wrote: >> However, I heard rumours that in order to make a Sage optional package >> uninstallable, one needs some new script analogous to spkg-install. >> >> Can someone give me a pointer on what should be done in that script and >> what tools (sdh_*) are available for it? > > That's not quite accurate. In general you do *not* need any > additional scripts, with some exception. > These packaging guidelines still need better documentation, but > essentially you need to make sure the package is built for what is > referred in GNU standards as a "DESTDIR install" [1]. This means that > the package is built for installation to some particular prefix (e.g. > `./configure --prefix=$SAGE_LOCAL` in autoconf terms), but can then be > *installed* with some additional path (the "DESTDIR") prepended to the > prefix. This is similar to providing an alternate root (e.g. prefix > is appended to DESTDIR instead of just "/"). Then what to do with p_group_cohomology? Its spkg-install script installs two sub-packages. Each of them, I think, follows the above scheme. However, Sage has no way of knowing that uninstalling p_group_cohomology means uninstalling two sub-packages. Perhaps one possibility is to split the current p_group_cohomology-3.3 into its two sub-packages, and make the first (which is autotoolized) a dependency for the second (which is a bunch of cython and python modules linked against the first sub-package. Say: - p_group_cohomology-3.4 shall only comprise what currently is the p/cython part of p_group_cohomology-3.3, and have modular_resolution as a dependency. - modular_resolution-1.0 shall only comprise what currently is the autotoolized c-library part of p_group_cohomology-3.3 Advantage: "make p_group_cohomology" would also install the dependency, hence, both packages get installed. And both packages can also be un-installed, I suppose. Disadvantage: The only purpose of modular_resolution-1.0 would be to serve as a dependency, it is (to my knowledge at least) of no independent use. Best regards, Simon -- 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/qpuqe5%247598%241%40blaine.gmane.org.
Re: [sage-devel] building Sage docs on small VMs
On Wed, Nov 6, 2019 at 12:50 PM E. Madison Bray wrote: > > On Mon, Nov 4, 2019 at 2:00 PM Dima Pasechnik wrote: > > > > How does one switch off multiprocessing in docbuild? > > (it's ludicrous not being able to build docs on a VM with 2GB of memory) > > The variable you're looking for I think is SAGE_NUM_THREADS=1 (note: I > think it will still fork at least once even with this). > still fails in the same way. What doesn't fail is SAGE_NUM_THREADS=1 ./sage -docbuild reference html I don't know how this is different from "make doc" > -- > 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/CAOTD34YyK2oosscfK80%2Ba7gX06%3DEXS%3Dyu3JJf1DEzvWcJhZprA%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/CAAWYfq2UAfCzfoP%3DhhSTEZBz2m7irwcMd85gpPLMjM3BGsC6yA%40mail.gmail.com.
Re: [sage-devel] building Sage docs on small VMs
On Mon, Nov 4, 2019 at 2:00 PM Dima Pasechnik wrote: > > How does one switch off multiprocessing in docbuild? > (it's ludicrous not being able to build docs on a VM with 2GB of memory) The variable you're looking for I think is SAGE_NUM_THREADS=1 (note: I think it will still fork at least once even with this). -- 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/CAOTD34YyK2oosscfK80%2Ba7gX06%3DEXS%3Dyu3JJf1DEzvWcJhZprA%40mail.gmail.com.
Re: [sage-devel] Can we adopt "orphan" Sage-related packages ?
Okay. Now these very useful tools can be properly maintained. Thank you, Sho. Thank you, Dima. Le mercredi 6 novembre 2019 13:34:49 UTC+1, Dima Pasechnik a écrit : > > On Wed, Nov 6, 2019 at 11:05 AM Sho Takemori > wrote: > > > > Thank you very much for transferring. > > > > > PS. I notice that sage-shell-mode misses a license. Should we add one > (GPL 3.0, as for all the other emacs lisp stuff we have). > > > > In the header of each file, it states it is under GPL v3.0, but to make > sure I have just added a LICENSE file. > > Thanks, great. Now Github also knows that it is under GPL 3.0. > > > > > -- > > 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-...@googlegroups.com . > > To view this discussion on the web visit > https://groups.google.com/d/msgid/sage-devel/a0041a01-0ed2-4ddd-acb2-3f9b716cf4df%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/c37db9c7-c29c-438a-935e-e0d4555e5753%40googlegroups.com.
Re: [sage-devel] Re: Package installation/uninstallation confusion
On Wed, Nov 6, 2019 at 7:58 AM Simon King wrote: > > On 2019-11-05, E. Madison Bray wrote: > > The generated file `build/make/Makefile` is output by the > > `./configure` script. In fact, that's its main purpose. When > > switching branches in this case the best thing to do is to re-run > > `./configure`. > > Concerning the original question how to uninstall stuff: In principle it > should be possible to cleanly uninstall p_group_cohomology, because it > consists of one autotoolized and one pip-installed sub-package. That's not the issue here; the issue is that when you uninstall the package files, some of the build system still needs to be reset. This is indeed a problem, and there should be a better way to handle what packages are or are not installed without necessarily having to re-run configure, but I haven't given much thought to it. > However, I heard rumours that in order to make a Sage optional package > uninstallable, one needs some new script analogous to spkg-install. > > Can someone give me a pointer on what should be done in that script and > what tools (sdh_*) are available for it? That's not quite accurate. In general you do *not* need any additional scripts, with some exception. These packaging guidelines still need better documentation, but essentially you need to make sure the package is built for what is referred in GNU standards as a "DESTDIR install" [1]. This means that the package is built for installation to some particular prefix (e.g. `./configure --prefix=$SAGE_LOCAL` in autoconf terms), but can then be *installed* with some additional path (the "DESTDIR") prepended to the prefix. This is similar to providing an alternate root (e.g. prefix is appended to DESTDIR instead of just "/"). This allows the package to be installed to a temporary "staging" area that makes it easy, in an otherwise agnostic way, to see exactly what files are going to be installed by the package so that we can generate a manifest from it. Any packaging using standard autoconf tools supports DESTDIR. Most CMake packages do as well I think but I forget if there's something special one has to do. Pip also supports this. Packages with weird custom build systems may need to be patched or worked around in other ways to support this, but fortunately there are not too many like that in Sage anymore. In some cases it is necessary to perform additional package installation steps more complicated than just copying files. In this case one can write an spkg-postinst script to perform such steps. This is mentioned here [2]. However, if an "spkg-postinst" installs or creates any files in $SAGE_LOCAL, although not necessarily required in all cases it might be good to uninstall those files as well, in which case one needs to write an "spkg-postrm" script. Normally this isn't necessary though, and there are only a few examples of this in use.* [1] https://www.gnu.org/prep/standards/html_node/DESTDIR.html [2] https://doc.sagemath.org/html/en/developer/packaging.html#build-and-install-scripts * One bug I am aware of in our packages is that there is a common file "share/info/dir" which some packages that support "info" modify/append to during installation. When using DESTDIR install this means a new share/info/dir file gets created, and then copied over any existing "share/info/dir". To handle this properly requires postinst/postrm scripts which handle this infodir for any packages that use it. I had a branch a long time ago that took care of this but it was part of a larger patchbomb and never got merged I think. However, it's not a high-priority issue; I don't think a lot of people are using `info` or someone would have complained by now, maybe... -- 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/CAOTD34ZmRQTJegm5f2zOVvFjOhhncQinRaTvj6SwFiVax4xQkg%40mail.gmail.com.
Re: [sage-devel] Can we adopt "orphan" Sage-related packages ?
On Wed, Nov 6, 2019 at 11:05 AM Sho Takemori wrote: > > Thank you very much for transferring. > > > PS. I notice that sage-shell-mode misses a license. Should we add one (GPL > > 3.0, as for all the other emacs lisp stuff we have). > > In the header of each file, it states it is under GPL v3.0, but to make sure > I have just added a LICENSE file. Thanks, great. Now Github also knows that it is under GPL 3.0. > > -- > 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/a0041a01-0ed2-4ddd-acb2-3f9b716cf4df%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/CAAWYfq0et0FK-d_6mR7YzT9AxzqSv%3DydK6K-UPqFgjvpMB5fcA%40mail.gmail.com.
Re: [sage-devel] Can we adopt "orphan" Sage-related packages ?
Thank you very much for transferring. > PS. I notice that sage-shell-mode misses a license. Should we add one (GPL 3.0, as for all the other emacs lisp stuff we have). In the header of each file, it states it is under GPL v3.0, but to make sure I have just added a LICENSE file. -- 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/a0041a01-0ed2-4ddd-acb2-3f9b716cf4df%40googlegroups.com.
Re: [sage-devel] Can we adopt "orphan" Sage-related packages ?
Dear Sho, dear all, the repos in question are now under SageMath Github org. https://github.com/sagemath?utf8=%E2%9C%93&q=&type=&language=emacs+lisp Thanks again to Sho for the contributions to SageMath over the years. Best, Dima PS. I notice that sage-shell-mode misses a license. Should we add one (GPL 3.0, as for all the other emacs lisp stuff we have). On Wed, Nov 6, 2019 at 9:20 AM Sho Takemori wrote: > > To transfer elisp repositories to the sagemath organization, a second step > transferring is necessary because I do not have a permission > (please refer to > https://help.github.com/en/github/administering-a-repository/transferring-a-repository#about-repository-transfers > ) for detail. > > I will transfer five elisp repos (ob-sagemath, auto-complete-sage, > company-sage, helm-sage, and anything-sage) to your account(@dimpase) on > github. Then, > > Please accept them. > And following > https://help.github.com/en/github/administering-a-repository/transferring-a-repository#transferring-a-repository-owned-by-your-user-account, > please transfer these 5 repositories to sagemath organization. > > > I am sorry for the trouble but thank your for your corporation. > > Best, > Sho Takemori > > > 2019年11月4日月曜日 20時55分25秒 UTC+9 Dima Pasechnik: >> >> On Sun, Nov 3, 2019 at 2:59 PM Emmanuel Charpentier >> wrote: >> > >> > Case in point: >> > >> > During a few years, someone called Sho Katemori created and maintained a >> > couple of (very) useful Sage-related packages fpr emacs users: >> > >> > sage-shell-mode: an emacs interface to Sage, allowing the integration of >> > typeset maths and 2D graphics in an emacs buffer managing a Sage >> > interactive session ; >> > ob-sagemath, an org-mode interface to Sage, alowing integration of "live" >> > Sage code snippets in a document ; >> > anything-sage, auto-complete-sage and helm sage, Sage extensions of >> > various emacs utilities. >> > >> > >> > Note: sage-shell-mode was a very welcome and timely replacement for the >> > old sage-mode package, deemed unmaintainable by its maintainer (Ivan >> > Andrus). It seems to have become popular (for Sage-reasonable values of >> > "popular", of course...). >> > >> > However, Sho Katemori seems to have dropped off the Net: his (her ?) last >> > contribution to his/hers Github repositories dates back to march 2018 ; an >> > attempt to mail him/her is still unanswered. As a consequence, those >> > package have some unanswered issues. >> > >> > It seems that sage-shell mode has been somehow "adopted" by Sage : its >> > current repository is now part of the Sage hierarchy on Github, which >> > allowed Frédéric Chapoton, then myself, to integrate some change needed >> > for Python 3 compatibility. >> > >> > I'd like to propose similar change to ob-sagemath ; it is also possible >> > that some other users may propose changes to the other packages (which are >> > not (yet) my cup of tea...). >> > >> > Hence the questions: >> > >> > Can we "adopt" these packages as we did for sage-shell-mode ? >> > If so, how ? >> >> The easiest would be if the author transferred the github repos to >> Sagemath github organization. >> I'm cc-ing this to all the email addresses I found on the web... >> >> If we don't get such a transfer done (which obviously needs the >> author's involvement) >> then we can just have copies of anything-sage, auto-complete-sage and >> helm sage hosted. >> >> ob-sage is harder, as it does not have a license... >> >> Best >> Dima >> > >> > >> > And, more generally: >> > >> > Do we have a policy about external but sage-related software suffering >> > "abandon" by their original authors/maintainers ? >> > >> > Advice requested... >> > >> > -- >> > 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-...@googlegroups.com. >> > To view this discussion on the web visit >> > https://groups.google.com/d/msgid/sage-devel/04893dfc-54d7-4edb-99c1-4ac9f50a9aef%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/b272bf4a-fe47-475d-b1b2-09e47ec57cb8%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/CAAWYfq0pa%3DdPQTfCQhjO85JquwVS2GF_7T-4mBYS-0ejSAmxtQ%40mail.gmail.com.
Re: [sage-devel] Can we adopt "orphan" Sage-related packages ?
Yes please, thanks a lot in advance. Your contributions are very valuable for SageMath project. On Wed, Nov 6, 2019 at 9:20 AM Sho Takemori wrote: > > To transfer elisp repositories to the sagemath organization, a second step > transferring is necessary because I do not have a permission > (please refer to > https://help.github.com/en/github/administering-a-repository/transferring-a-repository#about-repository-transfers > ) for detail. > > I will transfer five elisp repos (ob-sagemath, auto-complete-sage, > company-sage, helm-sage, and anything-sage) to your account(@dimpase) on > github. Then, > > Please accept them. > And following > https://help.github.com/en/github/administering-a-repository/transferring-a-repository#transferring-a-repository-owned-by-your-user-account, > please transfer these 5 repositories to sagemath organization. > > > I am sorry for the trouble but thank your for your corporation. > > Best, > Sho Takemori > > > 2019年11月4日月曜日 20時55分25秒 UTC+9 Dima Pasechnik: >> >> On Sun, Nov 3, 2019 at 2:59 PM Emmanuel Charpentier >> wrote: >> > >> > Case in point: >> > >> > During a few years, someone called Sho Katemori created and maintained a >> > couple of (very) useful Sage-related packages fpr emacs users: >> > >> > sage-shell-mode: an emacs interface to Sage, allowing the integration of >> > typeset maths and 2D graphics in an emacs buffer managing a Sage >> > interactive session ; >> > ob-sagemath, an org-mode interface to Sage, alowing integration of "live" >> > Sage code snippets in a document ; >> > anything-sage, auto-complete-sage and helm sage, Sage extensions of >> > various emacs utilities. >> > >> > >> > Note: sage-shell-mode was a very welcome and timely replacement for the >> > old sage-mode package, deemed unmaintainable by its maintainer (Ivan >> > Andrus). It seems to have become popular (for Sage-reasonable values of >> > "popular", of course...). >> > >> > However, Sho Katemori seems to have dropped off the Net: his (her ?) last >> > contribution to his/hers Github repositories dates back to march 2018 ; an >> > attempt to mail him/her is still unanswered. As a consequence, those >> > package have some unanswered issues. >> > >> > It seems that sage-shell mode has been somehow "adopted" by Sage : its >> > current repository is now part of the Sage hierarchy on Github, which >> > allowed Frédéric Chapoton, then myself, to integrate some change needed >> > for Python 3 compatibility. >> > >> > I'd like to propose similar change to ob-sagemath ; it is also possible >> > that some other users may propose changes to the other packages (which are >> > not (yet) my cup of tea...). >> > >> > Hence the questions: >> > >> > Can we "adopt" these packages as we did for sage-shell-mode ? >> > If so, how ? >> >> The easiest would be if the author transferred the github repos to >> Sagemath github organization. >> I'm cc-ing this to all the email addresses I found on the web... >> >> If we don't get such a transfer done (which obviously needs the >> author's involvement) >> then we can just have copies of anything-sage, auto-complete-sage and >> helm sage hosted. >> >> ob-sage is harder, as it does not have a license... >> >> Best >> Dima >> > >> > >> > And, more generally: >> > >> > Do we have a policy about external but sage-related software suffering >> > "abandon" by their original authors/maintainers ? >> > >> > Advice requested... >> > >> > -- >> > 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-...@googlegroups.com. >> > To view this discussion on the web visit >> > https://groups.google.com/d/msgid/sage-devel/04893dfc-54d7-4edb-99c1-4ac9f50a9aef%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/b272bf4a-fe47-475d-b1b2-09e47ec57cb8%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/CAAWYfq1jdQezUOA_PcgTxUOzraph-CuWZLAYbac0O2828xxK%2Bg%40mail.gmail.com.
Re: [sage-devel] Can we adopt "orphan" Sage-related packages ?
To transfer elisp repositories to the sagemath organization, a second step transferring is necessary because I do not have a permission (please refer to https://help.github.com/en/github/administering-a-repository/transferring-a-repository#about-repository-transfers ) for detail. I will transfer five elisp repos (ob-sagemath, auto-complete-sage, company-sage, helm-sage, and anything-sage) to your account(@dimpase) on github. Then, 1. Please accept them. 2. And following https://help.github.com/en/github/administering-a-repository/transferring-a-repository#transferring-a-repository-owned-by-your-user-account, please transfer these 5 repositories to sagemath organization. I am sorry for the trouble but thank your for your corporation. Best, Sho Takemori 2019年11月4日月曜日 20時55分25秒 UTC+9 Dima Pasechnik: > > On Sun, Nov 3, 2019 at 2:59 PM Emmanuel Charpentier > > wrote: > > > > Case in point: > > > > During a few years, someone called Sho Katemori created and maintained a > couple of (very) useful Sage-related packages fpr emacs users: > > > > sage-shell-mode: an emacs interface to Sage, allowing the integration of > typeset maths and 2D graphics in an emacs buffer managing a Sage > interactive session ; > > ob-sagemath, an org-mode interface to Sage, alowing integration of > "live" Sage code snippets in a document ; > > anything-sage, auto-complete-sage and helm sage, Sage extensions of > various emacs utilities. > > > > > > Note: sage-shell-mode was a very welcome and timely replacement for the > old sage-mode package, deemed unmaintainable by its maintainer (Ivan > Andrus). It seems to have become popular (for Sage-reasonable values of > "popular", of course...). > > > > However, Sho Katemori seems to have dropped off the Net: his (her ?) > last contribution to his/hers Github repositories dates back to march 2018 > ; an attempt to mail him/her is still unanswered. As a consequence, those > package have some unanswered issues. > > > > It seems that sage-shell mode has been somehow "adopted" by Sage : its > current repository is now part of the Sage hierarchy on Github, which > allowed Frédéric Chapoton, then myself, to integrate some change needed for > Python 3 compatibility. > > > > I'd like to propose similar change to ob-sagemath ; it is also possible > that some other users may propose changes to the other packages (which are > not (yet) my cup of tea...). > > > > Hence the questions: > > > > Can we "adopt" these packages as we did for sage-shell-mode ? > > If so, how ? > > The easiest would be if the author transferred the github repos to > Sagemath github organization. > I'm cc-ing this to all the email addresses I found on the web... > > If we don't get such a transfer done (which obviously needs the > author's involvement) > then we can just have copies of anything-sage, auto-complete-sage and > helm sage hosted. > > ob-sage is harder, as it does not have a license... > > Best > Dima > > > > > > And, more generally: > > > > Do we have a policy about external but sage-related software suffering > "abandon" by their original authors/maintainers ? > > > > Advice requested... > > > > -- > > 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-...@googlegroups.com . > > To view this discussion on the web visit > https://groups.google.com/d/msgid/sage-devel/04893dfc-54d7-4edb-99c1-4ac9f50a9aef%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/b272bf4a-fe47-475d-b1b2-09e47ec57cb8%40googlegroups.com.
Re: [sage-devel] Can we adopt "orphan" Sage-related packages ?
Thank you for the info. Then, I will transfer them to @dimpase on github. -- 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/111f395b-5cb6-441e-b7ec-78fea0b498c1%40googlegroups.com.
