On Fri, Aug 06, 2010 at 10:44:00AM -0400, kamaraju kusumanchi wrote: > On Fri, Aug 6, 2010 at 8:13 AM, Lucas Nussbaum <lu...@lucas-nussbaum.net> wrote: > > On 06/08/10 at 07:55 -0400, Kamaraju S Kusumanchi wrote: > >> According to > >> https://buildd.debian.org/fetch.cgi?pkg=sagemath;ver=3.0.5dfsg-5.1;ar... > >> the build of sagemath 3.0.5dfsg-5.1 failed due to a missing dependency on > >> libiml-dev . This package is now available. Could someone please reschedule > >> a build on alpha for sagemath?
> > That's probably not necessary, as the removal of sagemath has been > > requested (#573538).
> > - Lucas
> Hi Lucas,
> I am interested in seeing sagemath in Debian. I'd like to package it > for Debian with the help of others (of course). I am also willing to > spend time, maintain and collaborate with upstream. Based on the > discussions in bug:573538 there are many others who are interested to > help get sagemath into Debian.
> Here is my approach. It is based on the discussions from debconf10 > talks yesterday.
> 3) Next, I want to go step by step from 3.0.5dfsg-5.1 all the way upto > 4.5.1. So, I want to work on packaging 3.0.6 instead of 4.5.1 . Sure, > the upstream may not like it. But this way we will have a solid > understanding of what actually are the dependencies on the package.
Kamaraju,
Overall I like your plan. And I'd like to help.
I do not like starting with version 3.0.6. I think such an old version is unlikely to attract many users and hence testing will be suboptimal. In addition, upstream reports that upgrading to 4.5 is currently broken (http://sagemath.org/mirror/src/changelogs/sage-4.5.1.txt), so we know that older releases will incur substantial development challenges that even upstream is not supporting. Moreover, upstream releases very frequently (lately releases have occurred more often than once per month), so by the end of the squeeze+1 cycle we will experience many, many upgrade tests. So adding to the testing burden by doing a "dry run" with legacy versions seems to me to be a very inefficient use of volunteer time. Indeed, until the packaging process becomes very efficient (which might take substantial time), I think it would be smarter to conserve limited volunteer resources by not packaging some of the upstream releases.
So I think we should start with version 4.5.1 (or even version 4.5.2 if it comes out before our planning and team organizing work is done).
Note: I dropped debian-rele...@lists.debian.org and ftpmas...@ftp-master.debian.org from the CC: list as we are moving away from their areas of concern.
-- We are on a spaceship; a beautiful one. It took billions of years to develop. We're not going to get another. Now, how do we make this spaceship work? -- Buckminster Fuller
CJ Fearnley | Explorer in Universe c...@CJFearnley.com | Design Science Revolutionary http://www.CJFearnley.com | "Dare to be Naive" -- Bucky Fuller
> My understanding is that upstream is very unhappy with the fact that > Debian is shipping an old version, as it generates support requests for > something that they don't want to support (3.0.5 was released on > 2008-07-11).
Right. One of the points we have drive home to the users is that if they have a problem with the current version they have to try the latest available version before reporting that bug to either BTS or upstream. This again intersects a bit with the regression tests I mentioned before.
Normally, I'd expect that users DO NOT have the infrastructure to install the latest version. But if they pop up their problem on debian-science then one of us can test it and tell them if the problem goes away by compiling/installing the latest release. If the problem persists in the latest release, then it gets reported upstream.
This happens to me all the time with gfortran. I'll come across a code that goes boink when I use the current version of Debian. However, the gfortran devs only care if the problem is reproducible on the svn head. Due to lack of man power, they don't backport their patches. So, I ask on their mailing list if the problem is fixed in subsequent version. If the answer is yes, then I am happy to upgrade my gfortran. If the answer is no, then I report the bug.
Users do not want to install the latest version without knowing if their problem is fixed in the latest version. But if they know that the problem is fixed, then they make every effort to get that version.
> Removing the package from unstable doesn't prevent you from working on > the package. It's just a way to clean up Debian. It will be very easy to > re-upload when you will have something that builds in i386 and amd64 > (though it might be better to upload to experimental, as I doubt that > you will have something in a releasable state before a few months).
I agree. Actually removing the package might do some good in this case. We can concentrate on just i386 and amd64 and worry about other architectures later on. This might actually speed up things a bit.
> As for the strategy of working on the 3.X release or on the 4.X release, > I don't think that we should try to release something which is not > closer to the latest upstream release than 3.0.5.
Yes. The software released in Debian should be close to the latest 4.X release. I am thinking of having the intermediate versions somewhere in a private repository.
> I do not like starting with version 3.0.6. I think such an old version > is unlikely to attract many users and hence testing will be suboptimal. > In addition, upstream reports that upgrading to 4.5 is currently broken > (http://sagemath.org/mirror/src/changelogs/sage-4.5.1.txt), so we > know that older releases will incur substantial development challenges > that even upstream is not supporting. Moreover, upstream releases very > frequently (lately releases have occurred more often than once per month), > so by the end of the squeeze+1 cycle we will experience many, many upgrade > tests. So adding to the testing burden by doing a "dry run" with legacy > versions seems to me to be a very inefficient use of volunteer time. > Indeed, until the packaging process becomes very efficient (which might > take substantial time), I think it would be smarter to conserve limited > volunteer resources by not packaging some of the upstream releases.
You have a point. But the way I see it is this.
Sagemath is constantly updated at a rate greater than debian can cope up. I highly doubt we will ever be releasing the .deb packages as fast as they release the .tgz files. So, at some point we have to skip releases and provide as latest debs as possible. I understand that.
But now the situation is a bit different. Are we sure that we have all the deps of sagemath packaged into Debian? If the answer is yes, then I am happy to start with 4.5 right away.
If the answer is no then the next question is what is the minimal version that we can package given the current set of packages available in Debian. There is no clear cut approach. we need to go back and forth a bit. We may need to file some ITPs and work on some transitions which is where the team becomes important.
As for the support requests from users, sooner or later they realize that if there is a problem they have to go with the later version anyway. A bit of that frustration is probably good as it will drive some to come and take part in packaging sage for Debian.
On Sat, Aug 7, 2010 at 10:49 AM, <tabb...@ksplice.com> wrote: > On Fri, 6 Aug 2010, kamaraju kusumanchi wrote:
>> > Kamaraju,
>> > Overall I like your plan. And I'd like to help.
>> > I do not like starting with version 3.0.6. I think such an old version >> > is unlikely to attract many users and hence testing will be suboptimal. >> > In addition, upstream reports that upgrading to 4.5 is currently broken >> > (http://sagemath.org/mirror/src/changelogs/sage-4.5.1.txt), so we >> > know that older releases will incur substantial development challenges >> > that even upstream is not supporting. Moreover, upstream releases very >> > frequently (lately releases have occurred more often than once per month), >> > so by the end of the squeeze+1 cycle we will experience many, many upgrade >> > tests. So adding to the testing burden by doing a "dry run" with legacy >> > versions seems to me to be a very inefficient use of volunteer time. >> > Indeed, until the packaging process becomes very efficient (which might >> > take substantial time), I think it would be smarter to conserve limited >> > volunteer resources by not packaging some of the upstream releases.
>> You have a point. But the way I see it is this.
>> Sagemath is constantly updated at a rate greater than debian can cope >> up. I highly doubt we will ever be releasing the .deb packages as fast >> as they release the .tgz files. So, at some point we have to skip >> releases and provide as latest debs as possible. I understand that.
>> But now the situation is a bit different. Are we sure that we have all >> the deps of sagemath packaged into Debian? If the answer is yes, then >> I am happy to start with 4.5 right away.
> I think there are a couple new dependencies that are not in Debian; there > weren't any as of version 4.0 or so. I would recommend first getting > sagemath working building the copies contained in the sagemath tarball, > and then package them separately for Debian and switch over later in > development (this is how I did the original development, and it was much > easier to debug problems incrementally).
> I suspect that starting by doing the work incrementally with 3.0.6 first > might be easier than starting with 4.5 to begin with. There's a good > chance you'll want to switch tacts once you get the hang of it, but I > think if you try migrating the current package to 4.5, you'll end up > feeling overwhelmed by the problems and give up. Some partial progress of > mine on updating direct to 3.4.1 (shortly before 4.0) is available, in > case you find it useful (I don't think I was very far along):
> My experience is that one spends most of your time working on sagemath > packaging on (1) debugging and (2) waiting for it to build (it took about > 30 minutes to build on the server I was using). When I tried to update
Sage 4.5.x will take a lot longer than 30 minutes if you don't build in parallel. If you build the sagemath package in parallel in can take as little as 3 or 4 minutes on sage.math.washington.edu
> direct from 3.0.5 to 3.4.1, I found debugging problems resulting from > upstream changes took most of the time. I bet it would be much easier > when you can find the upstream change that caused the problem; since each > sagemath version has relatively small changes, that can make life easier, > especially if you're still getting used to dealing with the Sage build > system.
> One thing that I should warn you about is that now Debian has > substantially newer versions of various packages than Sage 3.0.5 was > designed for, and in some cases that will break things. The current Sage > 3.0.5 package was prepared for Lenny, and then tweaked a bit to keep it > compiling on newer stuff. So it's possible that the incremental approach > will prove to be painful and you don't want to do it. But if I were you, > I would probably start by just trying to do 3.0.5 -> 3.0.6, just because I > think that'll help build confidence and give you a better sense of the > nature of the challenge than going straight to 4.5.
> But it's really up to you. I don't have the time to help more than just > providing background information on how I did it and what problems I > encountered.
> -Tim Abbott
>> If the answer is no then the next question is what is the minimal >> version that we can package given the current set of packages >> available in Debian. There is no clear cut approach. we need to go >> back and forth a bit. We may need to file some ITPs and work on some >> transitions which is where the team becomes important.
>> As for the support requests from users, sooner or later they realize >> that if there is a problem they have to go with the later version >> anyway. A bit of that frustration is probably good as it will drive >> some to come and take part in packaging sage for Debian.
> -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com > For more options, visit this group at http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org
-- William Stein Professor of Mathematics University of Washington http://wstein.org
On Sat, 7 Aug 2010, William Stein wrote: > On Sat, Aug 7, 2010 at 10:49 AM, <tabb...@ksplice.com> wrote: > > I think there are a couple new dependencies that are not in Debian; there > > weren't any as of version 4.0 or so. I would recommend first getting > > sagemath working building the copies contained in the sagemath tarball, > > and then package them separately for Debian and switch over later in > > development (this is how I did the original development, and it was much > > easier to debug problems incrementally).
> > I suspect that starting by doing the work incrementally with 3.0.6 first > > might be easier than starting with 4.5 to begin with. There's a good > > chance you'll want to switch tacts once you get the hang of it, but I > > think if you try migrating the current package to 4.5, you'll end up > > feeling overwhelmed by the problems and give up. Some partial progress of > > mine on updating direct to 3.4.1 (shortly before 4.0) is available, in > > case you find it useful (I don't think I was very far along):
> > My experience is that one spends most of your time working on sagemath > > packaging on (1) debugging and (2) waiting for it to build (it took about > > 30 minutes to build on the server I was using). When I tried to update
> Sage 4.5.x will take a lot longer than 30 minutes if you don't build > in parallel. > If you build the sagemath package in parallel in can take as little as > 3 or 4 minutes > on sage.math.washington.edu
Yeah, unfortunately, the server I was using had only 2 cores.
Also, I should note that the 30 minutes was just the time to build the ~10 spkgs that weren't being dealt with as packages -- this was with using system packages for all the dependencies (I imagine your number is for building the whole thing?)
> > direct from 3.0.5 to 3.4.1, I found debugging problems resulting from > > upstream changes took most of the time. I bet it would be much easier > > when you can find the upstream change that caused the problem; since each > > sagemath version has relatively small changes, that can make life easier, > > especially if you're still getting used to dealing with the Sage build > > system.
> > One thing that I should warn you about is that now Debian has > > substantially newer versions of various packages than Sage 3.0.5 was > > designed for, and in some cases that will break things. The current Sage > > 3.0.5 package was prepared for Lenny, and then tweaked a bit to keep it > > compiling on newer stuff. So it's possible that the incremental approach > > will prove to be painful and you don't want to do it. But if I were you, > > I would probably start by just trying to do 3.0.5 -> 3.0.6, just because I > > think that'll help build confidence and give you a better sense of the > > nature of the challenge than going straight to 4.5.
> > But it's really up to you. I don't have the time to help more than just > > providing background information on how I did it and what problems I > > encountered.
> > -Tim Abbott
> >> If the answer is no then the next question is what is the minimal > >> version that we can package given the current set of packages > >> available in Debian. There is no clear cut approach. we need to go > >> back and forth a bit. We may need to file some ITPs and work on some > >> transitions which is where the team becomes important.
> >> As for the support requests from users, sooner or later they realize > >> that if there is a problem they have to go with the later version > >> anyway. A bit of that frustration is probably good as it will drive > >> some to come and take part in packaging sage for Debian.
> > -- > > To post to this group, send an email to sage-devel@googlegroups.com > > To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com > > For more options, visit this group at http://groups.google.com/group/sage-devel > > URL: http://www.sagemath.org
> -- > William Stein > Professor of Mathematics > University of Washington > http://wstein.org
> -- > You received this message because you are subscribed to the Google Groups "debian-sage" group. > To post to this group, send email to debian-sage@googlegroups.com. > To unsubscribe from this group, send email to debian-sage+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/debian-sage?hl=en.
On Sat, Aug 7, 2010 at 11:03 AM, Tim Abbott <tabb...@mit.edu> wrote: > On Sat, 7 Aug 2010, William Stein wrote:
>> On Sat, Aug 7, 2010 at 10:49 AM, <tabb...@ksplice.com> wrote: >> > I think there are a couple new dependencies that are not in Debian; there >> > weren't any as of version 4.0 or so. I would recommend first getting >> > sagemath working building the copies contained in the sagemath tarball, >> > and then package them separately for Debian and switch over later in >> > development (this is how I did the original development, and it was much >> > easier to debug problems incrementally).
>> > I suspect that starting by doing the work incrementally with 3.0.6 first >> > might be easier than starting with 4.5 to begin with. There's a good >> > chance you'll want to switch tacts once you get the hang of it, but I >> > think if you try migrating the current package to 4.5, you'll end up >> > feeling overwhelmed by the problems and give up. Some partial progress of >> > mine on updating direct to 3.4.1 (shortly before 4.0) is available, in >> > case you find it useful (I don't think I was very far along):
>> > My experience is that one spends most of your time working on sagemath >> > packaging on (1) debugging and (2) waiting for it to build (it took about >> > 30 minutes to build on the server I was using). When I tried to update
>> Sage 4.5.x will take a lot longer than 30 minutes if you don't build >> in parallel. >> If you build the sagemath package in parallel in can take as little as >> 3 or 4 minutes >> on sage.math.washington.edu
> Yeah, unfortunately, the server I was using had only 2 cores.
> Also, I should note that the 30 minutes was just the time to build the ~10 > spkgs that weren't being dealt with as packages -- this was with using > system packages for all the dependencies (I imagine your number is for > building the whole thing?)
I was just thinking about the sage core Python/Cython library. E.g., what gets built by
>> > direct from 3.0.5 to 3.4.1, I found debugging problems resulting from >> > upstream changes took most of the time. I bet it would be much easier >> > when you can find the upstream change that caused the problem; since each >> > sagemath version has relatively small changes, that can make life easier, >> > especially if you're still getting used to dealing with the Sage build >> > system.
>> > One thing that I should warn you about is that now Debian has >> > substantially newer versions of various packages than Sage 3.0.5 was >> > designed for, and in some cases that will break things. The current Sage >> > 3.0.5 package was prepared for Lenny, and then tweaked a bit to keep it >> > compiling on newer stuff. So it's possible that the incremental approach >> > will prove to be painful and you don't want to do it. But if I were you, >> > I would probably start by just trying to do 3.0.5 -> 3.0.6, just because I >> > think that'll help build confidence and give you a better sense of the >> > nature of the challenge than going straight to 4.5.
>> > But it's really up to you. I don't have the time to help more than just >> > providing background information on how I did it and what problems I >> > encountered.
>> > -Tim Abbott
>> >> If the answer is no then the next question is what is the minimal >> >> version that we can package given the current set of packages >> >> available in Debian. There is no clear cut approach. we need to go >> >> back and forth a bit. We may need to file some ITPs and work on some >> >> transitions which is where the team becomes important.
>> >> As for the support requests from users, sooner or later they realize >> >> that if there is a problem they have to go with the later version >> >> anyway. A bit of that frustration is probably good as it will drive >> >> some to come and take part in packaging sage for Debian.
>> > -- >> > To post to this group, send an email to sage-devel@googlegroups.com >> > To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com >> > For more options, visit this group at http://groups.google.com/group/sage-devel >> > URL: http://www.sagemath.org
>> -- >> William Stein >> Professor of Mathematics >> University of Washington >> http://wstein.org
>> -- >> You received this message because you are subscribed to the Google Groups "debian-sage" group. >> To post to this group, send email to debian-sage@googlegroups.com. >> To unsubscribe from this group, send email to debian-sage+unsubscribe@googlegroups.com. >> For more options, visit this group at http://groups.google.com/group/debian-sage?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "debian-sage" group. > To post to this group, send email to debian-sage@googlegroups.com. > To unsubscribe from this group, send email to debian-sage+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/debian-sage?hl=en.
-- William Stein Professor of Mathematics University of Washington http://wstein.org
On Fri, Aug 06, 2010 at 05:44:32PM -0400, kamaraju kusumanchi wrote: > But now the situation is a bit different. Are we sure that we have all > the deps of sagemath packaged into Debian? If the answer is yes, then > I am happy to start with 4.5 right away.
I believe everything else is either already in Debian or is really just a Sage SPKG that we can and should treat as upstream source. So the library situation is not too bad: most of the upstreams are actively maintained in Debian already!
I might have enough bandwidth to package gdmodule. Anyone want ratpoints or Cliquer? Anyone see how to handle the headaches that I identified?
On Mon, Aug 9, 2010 at 5:17 PM, CJ Fearnley <c...@cjfearnley.com> wrote: > On Fri, Aug 06, 2010 at 05:44:32PM -0400, kamaraju kusumanchi wrote: >> But now the situation is a bit different. Are we sure that we have all >> the deps of sagemath packaged into Debian? If the answer is yes, then >> I am happy to start with 4.5 right away.
> * eclib is Sage's packaging of mwrank. Neither eclib nor mwrank are > in Debian. Upstream has not changed in ages. I do not know of any > other software that depends on eclib besides sage. So we /might/ > be able to use sage's code/packaging and skip packaging it for Debian. > o http://www.sagemath.org/packages/standard/eclib-20080310.p10.txt
I've cc'd upstream = John Cremona, in case he wants to comment.
> * Cephes Mathematical Library. Not in Debian. I cannot find any licensing > statement upstream nor in Sage's SPKG. I think it is free, but > debian-{policy,legal} will complain if we try to package this. > Maybe we should lobby for its removal from sage? Or maybe the license > issues can be resolved? Or Debian's sage may just need to skip it? > o http://www.sagemath.org/packages/standard/cephes-2.8.txt
This is only currently needed on Cygwin. It will never be needed for Debian. Don't bother with it for Debian.
> * flintqs (SIMPQS): this seems to be part of flint (in Debian but old > version, see below) but Sage distributes it as a separate SPKG. > Uggh, my brain hurts.
When we included this in Sage, FLINT didn't exist. I've cc'd Bill Hart in case he wants to comment (again) about this. I think the upshot is that FlintQS should be removed as a separate package, though this could require substantial work due to how Sage uses qsieve. I'm not sure.
I think we only ship it since we need it in order to get GNUTLS, which we only need in order to provide a secure SSL mode for the Sage notebook. One could also just use openssl and completely get rid of the whole GNUTLS if Debian ships it as a system library and somehow dances around the non-GPL-compatible nature of OpenSSL. Making it easy to switch from GNUTLS to openssl for the Sage notebook would require a tiny amount of work by a notebook developers.
> I believe everything else is either already in Debian or is really just > a Sage SPKG that we can and should treat as upstream source. So the > library situation is not too bad: most of the upstreams are actively > maintained in Debian already!
> I might have enough bandwidth to package gdmodule. Anyone want ratpoints > or Cliquer? Anyone see how to handle the headaches that I identified?
> -- > You received this message because you are subscribed to the Google Groups "debian-sage" group. > To post to this group, send email to debian-sage@googlegroups.com. > To unsubscribe from this group, send email to debian-sage+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/debian-sage?hl=en.
-- William Stein Professor of Mathematics University of Washington http://wstein.org
Some comment from people doing the same kind of thing in Gentoo.
William already gave you a number of good comments, so I'll give a few details that I think you should know.
> On Fri, Aug 06, 2010 at 05:44:32PM -0400, kamaraju kusumanchi wrote: > * f2c: Debian (20090411-1+b1) is way newer than Sage (20070816.p2). > We might need to push Sage to upgrade.
As William said it is only used for scipy. Mainly because scipy in sage was built against BLAS/LAPACK reference implementation. Using ATLAS for those is fine and do not require f2c as ATLAS ship a CBLAS. Further on the subject of scipy, you need a version 0.7.x. scipy-0.7.2 will work. scipy-0.8 wants numpy-1.4 and sage is not going there yet. scipy shipped in sage includes this: http://projects.scipy.org/scipy/changeset/5790 you will get interesting doctest failure without.
We don't use scipy-sandox in Gentoo without problems but we may have the features somewhere in our scipy package.
*sympy: fine up to 0.6.6 there are breakages at version 0.6.7.
*pexpect: sage is stuck to a patched 2.0. 2.4 includes one of the two patches from sage. William and other will tell you that >pexect-2.0 is slow - not only that: some features of the notebook don't work properly with it (plotting is broken).
I was going to talk about jmol but you don't have java on alpha, do you?
Some version mismatches are OK, some aren't as you may infer from the above. Maxima is stuck at its current version and other versions break stuff. Funnily enough going to ecl-10.4 is ok but beware that sage is allergic to ecl compiled with unicode support: http://github.com/cschwan/sage-on-gentoo/issues/closed#issue/2
Since I haven't seen any updates on the work to build a Debian package for Sage, here is a summary of the past discussions that I believe is up-to-date: - I was mistaken about gdmodule: it is included in the Debian package python-gd. So no work is needed there. Good. - The Cephes Mathematical Library is only needed for Cygwin (Windows) and so is not required for Debian (William Stein). - f2c is only needed for Scipy and therefore should not be required for a Debian package because Debian already has Scipy (Fran ois Bissey, William Stein). - flintqs / SIMPQS issue. FlintQS should probably be removed as a SPKG in Sage, but it may require work (qsieve). Bill Hart may be able to comment further (William Stein). - opencdk / gnutls. William Stein thinks it is only needed to "provide a secure SSL mode for the Sage notebook". So we can probably use the Debian version of gnutls, but that will require assessment. - Issues Identified by Fran ois Bissey: * Scipy 0.6.7, which is in sid (Debian's development branch), will break things, at least because Sage's scipy requires this patch http://projects.scipy.org/scipy/changeset/5790 * Sage does not yet support scipy 0.8 because it depends on numpy-1.4 and "Sage is not going there yet". Strangely, Debian sid currently has scipy 0.7.2 (good), but includes numpy 1.4.1 (ut-oh). So that will probably create issues. * This pickles patch is still not integrated into Python upstream, but it is needed for Sage: http://bugs.python.org/issue7689 * This python2.6 issue probably affects sid: http://bugs.python.org/issue7491 which breaks stuff, witness: http://github.com/cschwan/sage-on-gentoo/issues#issue/1 * pexpect issue (Debian pkg: python-pexpect): Debian ships version 2.3, but Sage requires version 2.0 (though one of the necessary patches is already in 2.4). Plotting in the notebook is likely to break with newer versions that are in Debian; and >2.0 is reported to be slow. * ecl is OK unless compiled with Unicode support (http://github.com/cschwan/sage-on-gentoo/issues/closed#issue/2). Debian may do that, so it could be an issue. - There are still two unpackaged dependencies: ratpoints and cliquer. - There are at least five Debian packages that should be updated to newer upstream versions: libflint, libfplll0, gfan, lcalc, m4ri.
Giovanni Mascellani kindly put the old, buggy Debian Sage source code into git: git://git.debian.org/git/debian-science/packages/sagemath.git So we can build on Tim Abbott's prior work.
Did I miss any other issues?
So we need volunteers to help on at least the seven packages that are dependencies of Sage.
It might be helpful to maintain this "list of issues for Sage in Debian" so that it can be edited collectively. Where? How?
We also need volunteers to coordinate between the Sage, Upstream, and Debian package maintainers to resolve each of the documented issues.
Finally, it is still not clear to me who is on the team working to build a Debian Sage package. Is everyone interested on the debian-sage google group? Is there another place where the team should congregate to coordinate the work?
On Mon, Aug 09, 2010 at 08:17:43PM -0400, CJ Fearnley wrote: > On Fri, Aug 06, 2010 at 05:44:32PM -0400, kamaraju kusumanchi wrote: > > But now the situation is a bit different. Are we sure that we have all > > the deps of sagemath packaged into Debian? If the answer is yes, then > > I am happy to start with 4.5 right away.
> I believe everything else is either already in Debian or is really just > a Sage SPKG that we can and should treat as upstream source. So the > library situation is not too bad: most of the upstreams are actively > maintained in Debian already!
> I might have enough bandwidth to package gdmodule. Anyone want ratpoints > or Cliquer? Anyone see how to handle the headaches that I identified?
-- We are on a spaceship; a beautiful one. It took billions of years to develop. We're not going to get another. Now, how do we make this spaceship work? -- Buckminster Fuller
On Sat, Oct 02, 2010 at 06:04:22PM +0200, Giovanni Mascellani wrote: > Hi CJ, thanks for bringing this issue up again and for the summary.
> Il 01/10/2010 02:22, CJ Fearnley ha scritto: > > * Scipy 0.6.7, which is in sid (Debian's development branch), will > > break things, at least because Sage's scipy requires this patch > > http://projects.scipy.org/scipy/changeset/5790
> Why are you saying that scipy 0.6.7 is in sid? It seems to me that only > 0.7.2 is in sid (as your next point says).
Oops, I got cross-eyed:
Sympy is only OK (for Sage) up to version 0.6.6. 0.6.7 in sid will break (note from Fran ois Bissey).
> > Finally, it is still not clear to me who is on the team working to > > build a Debian Sage package. Is everyone interested on the debian-sage > > google group? Is there another place where the team should congregate > > to coordinate the work?
> I'd prefer using debian-scie...@l.d.o for this kind of task: it's a > Debian thing and it's totally appropriate on that list. I wholeheartedly > hate Google Groups (for example, for their absurd subscription policy) > and would like to keep Debian-related emails on Debian list archives.
Maybe we should trim the CC list to just debian-scie...@l.d.o and debian-sage@googlegroups.com (since I believe that would be preferred by some Sage people who do not want to bother with all of debian-scie...@l.d.o). Would that satisfy everyone on the (overly broad) CC list?
-- We are on a spaceship; a beautiful one. It took billions of years to develop. We're not going to get another. Now, how do we make this spaceship work? -- Buckminster Fuller
On Sat, Oct 2, 2010 at 9:34 AM, CJ Fearnley <c...@cjfearnley.com> wrote: > On Sat, Oct 02, 2010 at 06:04:22PM +0200, Giovanni Mascellani wrote: >> Hi CJ, thanks for bringing this issue up again and for the summary.
>> Il 01/10/2010 02:22, CJ Fearnley ha scritto: >> > * Scipy 0.6.7, which is in sid (Debian's development branch), will >> > break things, at least because Sage's scipy requires this patch >> > http://projects.scipy.org/scipy/changeset/5790
>> Why are you saying that scipy 0.6.7 is in sid? It seems to me that only >> 0.7.2 is in sid (as your next point says).
> Oops, I got cross-eyed:
> Sympy is only OK (for Sage) up to version 0.6.6. 0.6.7 in sid will break > (note from François Bissey).
It's some problem in Sage vs sympy and it should probably be fixed upstream, either in Sage or in sympy. If someone has time to work on that, it'd be great.
On Mon, Oct 04, 2010 at 02:26:39PM -0700, Ondrej Certik wrote: > On Sat, Oct 2, 2010 at 9:34 AM, CJ Fearnley <c...@cjfearnley.com> wrote:
> > Sympy is only OK (for Sage) up to version 0.6.6. 0.6.7 in sid will break > > (note from Fran ois Bissey).
> It's some problem in Sage vs sympy and it should probably be fixed > upstream, either in Sage or in sympy. If someone has time to work on > that, it'd be great.
Has anyone characterized the problem enough to write a bug report?
I don't even know what we should be looking for.
-- We are on a spaceship; a beautiful one. It took billions of years to develop. We're not going to get another. Now, how do we make this spaceship work? -- Buckminster Fuller
> I found the hint below in another thread. But what are the issues > with > upgrading sympy to v. 0.6.7? I could not find a ticket in trac (did I > miss > it)?
I just tried to upgrade it and run tests and it didn't work. I currently don't have time to investigate further. If someone could make the upgrade, it'd be great. I'll help with resolving any potential issues.
