[sage-devel] Re: GSoC project: make the Sage build system more distribution friendly
Am Samstag, 16. März 2013 20:57:13 UTC+1 schrieb leif: > > Julien Puydt wrote: > > The proposition isn't to fork sage to get it into a single distribution, > > but to modify it with upstream so any distribution can easily package it > > correctly. > > But if we switch to git, improve Sage's package management (as a first > step, split vanilla upstream sources off the spkgs :P ), ... > Is splitting the vanilla upstream sources off planned? That would be very helpful for distributions. Another helpful thing would be a clear distinction between fixes/adjustment to the library and Sage glue, because we need all the Sage glue, but want to decide ourselves which other patches to apply. Another thing are patch headers. Sometimes I can't find out what a patch in a spkg does, for example I found patches that just move a few lines of code somewhere else. I can't apply a patch when I don't know what it does. In Debian we have this specification for patch headers to document what they do: http://dep.debian.net/deps/dep3/ > > I'd be happy if Sage in whole was more modular / less monolithic; I'm > not very optimistic regarding the Sage /library/ though. > What do you mean with the Sage /library/? -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: GSoC project: make the Sage build system more distribution friendly
Sorry, there were a few mails that missed the list:
On 09.04.2013 09:49, Felix Salfelder wrote:
> Hi
>
> thanks for establishing this!
>
> i can imagine applying for that project. at least i'll have some time
> left in summer, as i'm on parental leave and i found a nursery...
> i'd like to discuss the scope and potential solutions for that problem a
> bit.
>
> a proper build system for sage ("the library") with the usual dependency
> checks seems neccesary (if not sufficient) for distributions. i can think
of
> a way to implement this (probably using autotools) and put it into a
> debian package. such a build system won't yet get me much closer to the
> project deliverable "support for choosing a set of dependencies within
> sage" without messing a lot with sage ("the operating system").
>
> a build system for sage ("the library") could be used to switch between
> system headers/libraries and stuff installed to /some/sage/prefix.
> in order to make use of these switches from sage ("the operating
> system"), the toplevel install script must be able process switches like
> --with-ntl=/usr/include to pass to the spkg compilation, which in turn
> means *all* spkgs must understand such flags (doesn't it?).
>
> it seems to be more work to fix sage ("the operating sytstem") than to
> properly ship sage ("the library") within an already working
> distribution (= properly checking for functionality/applied patches).
> these checks however are difficult to maintain, if upstream sage doesn't
> use them...
>
> to me, these problems (fixing sage vs. distributing sage library) seem
> independent enough to have two GSoC projects. i have a rough idea of
> what gentoo-prefix is doing and of Julien's pruner script, but i don't
> see a solution there. what is your favourite way out?
>
> regards
> felix
--
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: GSoC project: make the Sage build system more distribution friendly
On 09.04.2013 10:26, Tobias Hansen wrote:
> Hi Felix,
>
> On 04/09/2013 09:49 AM, Felix Salfelder wrote:
>> a proper build system for sage ("the library") with the usual dependency
>> checks seems neccesary (if not sufficient) for distributions. i can
>> think of
>> a way to implement this (probably using autotools) and put it into a
>> debian package. such a build system won't yet get me much closer to the
>> project deliverable "support for choosing a set of dependencies within
>> sage" without messing a lot with sage ("the operating system").
>>
>> a build system for sage ("the library") could be used to switch between
>> system headers/libraries and stuff installed to /some/sage/prefix.
>> in order to make use of these switches from sage ("the operating
>> system"), the toplevel install script must be able process switches like
>> --with-ntl=/usr/include to pass to the spkg compilation, which in turn
>> means *all* spkgs must understand such flags (doesn't it?).
>
> No, the toplevel install script must just be able to skip the
> compilation of these spkg's. And tell the Sage library to use the
> libraries that are available and were compiled independently.
>
>> it seems to be more work to fix sage ("the operating sytstem") than to
>> properly ship sage ("the library") within an already working
>> distribution (= properly checking for functionality/applied patches).
>> these checks however are difficult to maintain, if upstream sage doesn't
>> use them...
>
> We want to do the changes to the build system in Sage, the two Sage
> developers agreed to keep an eye on the progress so that we end up with
> something they can accept in the end. As much tests as possible would be
> great, but how would you check for applied patches in an universal way?
> Every distribution has its own way to organize patches. I think Sage
> already has a good test coverage and a Debian package should of course
> run all the tests during build.
>
>>
>> to me, these problems (fixing sage vs. distributing sage library) seem
>> independent enough to have two GSoC projects. i have a rough idea of
>> what gentoo-prefix is doing and of Julien's pruner script, but i don't
>> see a solution there. what is your favourite way out?
>>
>> regards
>> felix
> It seems to me that you understood that Sage should build all spkg's in
> any case and just install them somewhere else. I think that means the
> step you call "fix Sage the operating system" is not needed right? Now
> that I have clarified this, any new thoughts?
>
> Cheers,
> Tobias
--
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: GSoC project: make the Sage build system more distribution friendly
On 09.04.2013 14:18, Tobias Hansen wrote:
> On 04/09/2013 10:26 AM, Tobias Hansen wrote:
>>>
>>> a build system for sage ("the library") could be used to switch between
>>> system headers/libraries and stuff installed to /some/sage/prefix.
>>> in order to make use of these switches from sage ("the operating
>>> system"), the toplevel install script must be able process switches like
>>> --with-ntl=/usr/include to pass to the spkg compilation, which in turn
>>> means *all* spkgs must understand such flags (doesn't it?).
>>
>> No, the toplevel install script must just be able to skip the
>> compilation of these spkg's. And tell the Sage library to use the
>> libraries that are available and were compiled independently.
>>
>
> I get it, you are talking about dependencies between spkg's. Yes that
> would require a central mechanism in Sage that provides all spkgs with
> the information where the other stuff is, if we really want the
> possibility to mix spkgs and system libraries.
--
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: GSoC project: make the Sage build system more distribution friendly
On 10.04.2013 17:43, Felix Salfelder wrote:
> Hi Tobias
>
> On Tue, Apr 09, 2013 at 10:26:30AM +0200, Tobias Hansen wrote:
>> No, the toplevel install script must just be able to skip the
>> compilation of these spkg's. And tell the Sage library to use the
>> libraries that are available and were compiled independently.
>
> skipping compilation of spkgs (and the installation to
> /some/sage/prefix) and appending CPP/LD-FLAGS to environment variables
> during spkg builds seems feasible. this would require a configure
> script (or configure functionality)...
>
> picking the right flags for each spkg and/or fixing every single spkg to
> use them (correctly) is probably more work.
>
>>> it seems to be more work to fix sage ("the operating sytstem") than to
>>> properly ship sage ("the library") within an already working
>>> distribution (= properly checking for functionality/applied patches).
>>> these checks however are difficult to maintain, if upstream sage doesn't
>>> use them...
>
> i should write "sage the system", what i'm referring to is the tarball
> that contains the spkg's and the toplevel 'installer' makefile.
>
>> We want to do the changes to the build system in Sage, the two Sage
>> developers agreed to keep an eye on the progress so that we end up
>> with something they can accept in the end.
>
> several parts of fixing/changing/improving the sage (the system) build
> system is unrelated to distributing sage "the library". so "changes to
> the build system in Sage" is somewhat vague.
>
>> As much tests as possible
>> would be great, but how would you check for applied patches in an
>> universal way?
>
> i think a build system for the sage library should at least check
> availibility (especially optional dependencies). more checks for
> versions/header functionality/existing symbols are implemented within
> autotools. the universal way would be maintaining these checks (which is
> unrealistic). catching common caveats should be possible.
>
>> Every distribution has its own way to organize
>> patches. I think Sage already has a good test coverage and a Debian
>> package should of course run all the tests during build.
>
> iirc the tests are contained within sage.spkg (where the library is), so
> that should be possible. other tests may come within other spkgs.
>
>> It seems to me that you understood that Sage should build all spkg's
>> in any case and just install them somewhere else. I think that means
>> the step you call "fix Sage the operating system" is not needed
>> right? Now that I have clarified this, any new thoughts?
>
> for debian or other distributions, i dont see the need for any changes
> to sage (the system). making sagelib distributable doesn't help skipping
> spkgs. so there are still two subprojects:
>
> - improve sage (the library) distributability
> - enhance setup.py (better switch to autotools)
> - get libcsage.deb and python-sage.deb packages
> - run the unit tests from debian/rules
> - (also pack other stuff)
> - pave the way for local spkgs (e.g. installed to ~/.sage/local)
> - [..]
> - "fix sage the system"
> - implement/incorporate top level configure script
> - figure out flags, pass down to spkg-compilation
> - build sage the upstream way skipping some spkgs
> - [..]
>
> in fact, the second is not needed, neither for me, nor for the debian
> package. the project description implies something different, which is
> confusing.
>
> depending on difficulties, i might be able do deal with both. but of
> course i want to clarify the details before i apply :)
>
> thanks
> felix
On 10.04.2013 17:52, Felix Salfelder wrote:
> On Tue, Apr 09, 2013 at 02:18:06PM +0200, Tobias Hansen wrote:
>> I get it, you are talking about dependencies between spkg's. Yes
>> that would require a central mechanism in Sage that provides all
>> spkgs with the information where the other stuff is, if we really
>> want the possibility to mix spkgs and system libraries.
>
> yes. something like that.
>
> but it seems to be a lot of uneccesary/duplicate work. it's probably
> more adequate to just skip spkgs and cross fingers -- for that matter.
>
> regards
> felix
--
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] License of the SageMath documentation
Hi, I found conflicting information about the license of the SageMath documentation. While it says nothing in COPYING.txt, it says in src/doc/en/reference/history_and_license/index.rst that "All documentation is released under the GNU Free Documentation License." On the other hand, there are many files, for example src/doc/en/reference/index.rst which state "This work is licensed under a `Creative Commons Attribution-Share Alike 3.0 License`__." So which one is true? This should be clarified in the sources. Best, Tobias -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Python 2.7.13rc1 breaks UnknownClass
Hi sage-devel, we're almost ready to upload Sage to Debian (in fact we basically have to upload it this week to make sure it's included in the next Debian release). However, on Sunday python 2.7.13rc1 was uploaded to Debian and now we are facing a bug that I didn't quite manage to work around yet and that blocks any development at the moment. This happens whenever Unknown is imported, meaning during the docbuild and when starting sage: ... from sage.misc.unknown import Unknown File "/usr/lib/python2.7/dist-packages/sage/misc/unknown.py", line 164, in Unknown = UnknownClass() File "sage/misc/classcall_metaclass.pyx", line 330, in sage.misc.classcall_metaclass.ClasscallMetaclass.__call__ (/sage/misc/classcall_metaclass.c:1413) File "sage/misc/cachefunc.pyx", line 1059, in sage.misc.cachefunc.CachedFunction.__call__ (/sage/misc/cachefunc.c:6080) File "/usr/lib/python2.7/dist-packages/sage/structure/unique_representation.py", line 1022, in __classcall__ instance = typecall(cls, *args, **options) File "sage/misc/classcall_metaclass.pyx", line 497, in sage.misc.classcall_metaclass.typecall (/sage/misc/classcall_metaclass.c:1862) TypeError: sage.misc.fast_methods.WithEqualityById.__new__(UnknownClass) is not safe, use object.__new__() I'm pretty sure it's caused by the change of https://bugs.python.org/issue5322 which is included in python 2.7.13rc1. I hope you can help me to fix this, or at least provide a workaround. Best, Tobias -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Python 2.7.13rc1 breaks UnknownClass
Am Mittwoch, 7. Dezember 2016 01:43:09 UTC schrieb tha...@debian.org: > > On 12/07/2016 01:27 AM, François Bissey wrote: > > On 07/12/16 12:20, tha...@debian.org wrote: > >> Hi sage-devel, > >> > >> we're almost ready to upload Sage to Debian (in fact we basically have > >> to upload it this week to make sure it's included in the next Debian > >> release). > >> > >> However, on Sunday python 2.7.13rc1 was uploaded to Debian and now we > >> are facing a bug that I didn't quite manage to work around yet and that > >> blocks any development at the moment. > >> > >> This happens whenever Unknown is imported, meaning during the docbuild > >> and when starting sage: > >> > >> ... > >> from sage.misc.unknown import Unknown > >> File > >> "/usr/lib/python2.7/dist-packages/sage/misc/unknown.py", line > >> 164, in > >> Unknown = UnknownClass() > >> File "sage/misc/classcall_metaclass.pyx", line 330, in > >> sage.misc.classcall_metaclass.ClasscallMetaclass.__call__ > >> (/sage/misc/classcall_metaclass.c:1413) > >> File "sage/misc/cachefunc.pyx", line 1059, in > >> sage.misc.cachefunc.CachedFunction.__call__ > >> (/sage/misc/cachefunc.c:6080) > >> File > >> > "/usr/lib/python2.7/dist-packages/sage/structure/unique_representation.py", > > > >> > >> line 1022, in __classcall__ > >> instance = typecall(cls, *args, **options) > >> File "sage/misc/classcall_metaclass.pyx", line 497, in > >> sage.misc.classcall_metaclass.typecall > >> (/sage/misc/classcall_metaclass.c:1862) > >> TypeError: > sage.misc.fast_methods.WithEqualityById.__new__(UnknownClass) > >> is not safe, use object.__new__() > >> > >> I'm pretty sure it's caused by the change of > >> https://bugs.python.org/issue5322 > >> which is included in python 2.7.13rc1. > >> > >> I hope you can help me to fix this, or at least provide a workaround. > >> > > > > What did you try so far? > > The most obvious thing to try, as far as I can see, is to add > > __new__ = object.__new__() > > before > > def __init__(self): > > in sage/misc/unknown.py > > > > Francois > > > > I created a minimal cython example with classes and cdef classes that > inherit from each other in the same way as here to see if this is caused > by WithEqualityById being a cdef class. In the example everything worked > as it should. > > Just because it appears in the error message I also tried replacing the > two > (type).tp_call(cls, args, kwds) > in > sage/misc/classcall_metaclass.pyx > by > type.__call__(cls, *args, **kwds). > > That didn't help either. > > I'll try your suggestion next, thanks. > > Best, Tobias > When setting __new__ = object.__new__() for UnknownClass it goes on to the next similar error: ... File "/usr/lib/python2.7/dist-packages/sage/categories/sets_cat.py", line 2752, in cartesian_product = CartesianProductFunctor() File "sage/misc/classcall_metaclass.pyx", line 330, in sage.misc.classcall_metaclass.ClasscallMetaclass.__call__ (/sage/misc/classcall_metaclass.c:1413) File "sage/misc/cachefunc.pyx", line 1059, in sage.misc.cachefunc.CachedFunction.__call__ (/sage/misc/cachefunc.c:6080) File "/usr/lib/python2.7/dist-packages/sage/structure/unique_representation.py", line 1022, in __classcall__ instance = typecall(cls, *args, **options) File "sage/misc/classcall_metaclass.pyx", line 497, in sage.misc.classcall_metaclass.typecall (/sage/misc/classcall_metaclass.c:1862) TypeError: sage.misc.fast_methods.WithEqualityById.__new__(CartesianProductFunctor) is not safe, use sage.categories.functor.Functor.__new__() -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: License of the SageMath documentation
The GNU Free Documentation License is not considered a free license by Debian. So if it's this, it can't be included in Debian. :( See https://wiki.debian.org/DFSGLicenses#GNU_Free_Documentation_License_.28GFDL.29 Am Sonntag, 4. Dezember 2016 21:45:27 UTC schrieb tha...@debian.org: > > Hi, > > I found conflicting information about the license of the SageMath > documentation. > > While it says nothing in COPYING.txt, it says in > src/doc/en/reference/history_and_license/index.rst that "All documentation > is released under the GNU Free Documentation License." > > On the other hand, there are many files, for example > src/doc/en/reference/index.rst which state "This work is licensed under a > `Creative Commons Attribution-Share Alike 3.0 License`__." > > So which one is true? This should be clarified in the sources. > > Best, > Tobias > -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Non-Sage C code in the Sage library
Whether it is an embedded fork in sage or it gets its own git repo on the sage github account.. Someone from the sage community would have to fix bugs in both cases. Am Freitag, 24. April 2015 10:37:56 UTC+2 schrieb John Cremona: > > Who is the author of hyperellfrob? > > There is a point in addition to Michael's: maintaining a fork which > only differs with respect to libtools packaging is one thing, but we > would also need someone to take responsibility for any bugs found in > the code, if the original author was not able, willing or available to > respond. > > John > > On 24 April 2015 at 00:54, Michael Orlitzky > wrote: > > On 04/23/2015 04:56 PM, Jeroen Demeyer wrote: > >>> > >>> Can't we work with upstream (the authors) to package these? > >> For starters, none of these seem very active projects. In particular, > >> hyperellfrob and bernmm have their last release in 2008 and 2009. > >> > >> Second, what if the authors don't care? > >> > > > > There are two kinds of don't care: > > > > 1. The author doesn't like autotools or doesn't want to accept > > outside contributions. > > > > 2. The code was for an old project and the author can't be bothered > > with it any more. > > > > Both have the same solution: fork it and make releases on the sagemath > > github or wherever. In the case of (2), this is obviously best for > > everyone. If it's (1) instead, then most of our additions will be > > independent of the "real" code making it trivial for us to merge > > upstream changes. Then our fork will be the better fork (since it builds > > easily and has all the same features), and people will use our fork > > instead. Eventually the author will come around, or if not, that's not a > > huge problem either. > > > > We're essentially maintaining a fork now, so it wouldn't necessarily be > > more work after we're done auto-tooling it. > > > > -- > > 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 post to this group, send email to sage-...@googlegroups.com > . > > Visit this group at http://groups.google.com/group/sage-devel. > > For more options, visit https://groups.google.com/d/optout. > -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
