42 views

Skip to first unread message

Aug 6, 2010, 11:52:59 AM8/6/10

to kamaraju kusumanchi, tab...@mit.edu, Lucas Nussbaum, 573...@bugs.debian.org, Rogério Brito, David Bremner, debian-...@lists.debian.org, mryan...@cox.net, Sami Losoi, debia...@googlegroups.com, sage-...@googlegroups.com, kumar....@gmail.com

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;arch=alpha;stamp=1263382158

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

> 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;arch=alpha;stamp=1263382158

> >> 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-...@lists.debian.org and

ftpm...@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

Aug 6, 2010, 6:00:19 PM8/6/10

to Lucas Nussbaum, debian-...@lists.debian.org, tab...@mit.edu, 573...@bugs.debian.org, Rogério Brito, David Bremner, debian-...@lists.debian.org, mryan...@cox.net, Sami Losoi, CJ Fearnley, debia...@googlegroups.com, sage-...@googlegroups.com, ftpm...@ftp-master.debian.org, kumar....@gmail.com

>

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

>

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

Aug 6, 2010, 5:44:32 PM8/6/10

to CJ Fearnley, tab...@mit.edu, Lucas Nussbaum, 573...@bugs.debian.org, Rogério Brito, David Bremner, debian-...@lists.debian.org, mryan...@cox.net, Sami Losoi, debia...@googlegroups.com, sage-...@googlegroups.com, kumar....@gmail.com

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

>

>

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

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.

thanks

raju

Aug 7, 2010, 1:59:36 PM8/7/10

to sage-...@googlegroups.com, kamaraju kusumanchi, CJ Fearnley, Lucas Nussbaum, 573...@bugs.debian.org, Rogério Brito, David Bremner, debian-...@lists.debian.org, mryan...@cox.net, Sami Losoi, debia...@googlegroups.com, kumar....@gmail.com

On Sat, Aug 7, 2010 at 10:49 AM, <tab...@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):

>

> http://web.mit.edu/sage/www/sage-3.4.1-debian.tar.gz

>

> 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

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

>

> 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):

>

> http://web.mit.edu/sage/www/sage-3.4.1-debian.tar.gz

>

> 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

-- William

> 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-...@googlegroups.com

> To unsubscribe from this group, send an email to sage-devel+...@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

Aug 7, 2010, 2:03:21 PM8/7/10

to debia...@googlegroups.com, sage-...@googlegroups.com, kamaraju kusumanchi, CJ Fearnley, Lucas Nussbaum, 573...@bugs.debian.org, Rogério Brito, David Bremner, debian-...@lists.debian.org, mryan...@cox.net, Sami Losoi, kumar....@gmail.com

On Sat, 7 Aug 2010, William Stein wrote:

> On Sat, Aug 7, 2010 at 10:49 AM, <tab...@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):

> >

> > http://web.mit.edu/sage/www/sage-3.4.1-debian.tar.gz

> >

> > 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?)

-Tim Abbott

> --

> You received this message because you are subscribed to the Google Groups "debian-sage" group.

> To post to this group, send email to debia...@googlegroups.com.

> To unsubscribe from this group, send email to debian-sage...@googlegroups.com.

> For more options, visit this group at http://groups.google.com/group/debian-sage?hl=en.

>

>

Aug 7, 2010, 2:09:41 PM8/7/10

to debia...@googlegroups.com, sage-...@googlegroups.com, kamaraju kusumanchi, CJ Fearnley, Lucas Nussbaum, 573...@bugs.debian.org, Rogério Brito, David Bremner, debian-...@lists.debian.org, mryan...@cox.net, Sami Losoi, kumar....@gmail.com

I was just thinking about the sage core Python/Cython library. E.g.,

what gets built by

sage -ba

William

Aug 9, 2010, 8:17:43 PM8/9/10

to kamaraju kusumanchi, tab...@mit.edu, Lucas Nussbaum, Rogério Brito, debian-...@lists.debian.org, mryan...@cox.net, Sami Losoi, debia...@googlegroups.com, sage-...@googlegroups.com, kumar....@gmail.com

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.

> 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 spent some time analyzing the components of sage-4.5.2 which was released

recently. I looked at http://www.sagemath.org/packages/standard/ and

http://www.sagemath.org/links-components.html and used packages.debian.org to

see what we have available. Here is my first cut assessment:

* 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

* 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

* Cliquer. Needs a Debian package.

o http://www.sagemath.org/packages/standard/cliquer-1.2.p5.txt

* Data files. I think we can ship the following SPKG's as part of Sage and

do not need to package them for Debian, since they appear to be data files

only:

o http://www.sagemath.org/packages/standard/conway_polynomials-0.2.txt

o http://www.sagemath.org/packages/standard/elliptic_curves-0.1.txt

o http://www.sagemath.org/packages/standard/examples-4.5.2.txt

o http://www.sagemath.org/packages/standard/extcode-4.5.2.txt

o http://www.sagemath.org/packages/standard/graphs-20070722.p1.txt

o http://www.sagemath.org/packages/standard/polytopes_db-20100210.txt

* extcode: a miscellany. Appears to have Tim's debian subdirectory for

building the package, jsMath, and tons of other stuff. Most (all?) of

it is not a problem (jsMath is already in Debian, but which version

is included in Sage is not clear to me), but some things may require

finding upstream and building a Debian package. More work needed.

o http://www.sagemath.org/packages/standard/extcode-4.5.2.txt

* f2c: Debian (20090411-1+b1) is way newer than Sage (20070816.p2).

We might need to push Sage to upgrade.

o http://www.sagemath.org/packages/standard/f2c-20070816.p2.txt

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

o http://www.sagemath.org/packages/standard/flintqs-20070817.p5.txt

* gdmodule. Needs a Debian package.

o http://www.sagemath.org/packages/standard/gdmodule-0.56.p7.txt

* opencdk. This ships as part of gnutls. However, sage's fork differs

quite a bit from the code in gnutls. Do we need a package or is it

part of gnutls with no work needed? I don't know.

o http://www.sagemath.org/packages/standard/opencdk-0.6.6.p5.txt

* ratpoints. Needs a Debian package.

o http://www.sagemath.org/packages/standard/ratpoints-2.1.3.p1.txt

* rubiks. I think these three upstream "packages" are too small to

package for Debian. I recommend using sage's source for them.

o http://www.sagemath.org/packages/standard/rubiks-20070912.p12.txt

* scipy_sandbox. Seems to include a few optional/experimental scipy

packages. They do not appear to be in Debian, but are probably too small

to warrant separate packages.

o http://www.sagemath.org/packages/standard/scipy_sandbox-20071020.p5.txt

New versions needed in Debian:

* I submitted http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592349

since libflint is out of date

* I submitted http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592349

since libfplll0 is out of date

* I submitted http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592425

since gfan is out of date

* I submitted http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592426

since lcalc is out of date

* I submitted http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592429

since m4ri is out of date

* I did not go through all dependencies comprehensively looking for

Sage/Debian version mismatch issues. More work needed.

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?

--

CJ Fearnley | LinuxForce Inc.

c...@LinuxForce.net | IT Projects & Systems Maintenance

http://www.LinuxForce.net | http://blog.remoteresponder.net

Aug 9, 2010, 8:28:35 PM8/9/10

to debia...@googlegroups.com, kamaraju kusumanchi, tab...@mit.edu, Lucas Nussbaum, Rogério Brito, debian-...@lists.debian.org, mryan...@cox.net, Sami Losoi, sage-...@googlegroups.com, kumar....@gmail.com, Cremona John, Bill Hart

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.

>

> I spent some time analyzing the components of sage-4.5.2 which was released

> recently. I looked at http://www.sagemath.org/packages/standard/ and

> http://www.sagemath.org/links-components.html and used packages.debian.org to

> see what we have available. Here is my first cut assessment:

>

> * 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

> 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 spent some time analyzing the components of sage-4.5.2 which was released

> recently. I looked at http://www.sagemath.org/packages/standard/ and

> http://www.sagemath.org/links-components.html and used packages.debian.org to

> see what we have available. Here is my first cut assessment:

>

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

> * Cliquer. Needs a Debian package.

> o http://www.sagemath.org/packages/standard/cliquer-1.2.p5.txt

> * Data files. I think we can ship the following SPKG's as part of Sage and

> do not need to package them for Debian, since they appear to be data files

> only:

> o http://www.sagemath.org/packages/standard/conway_polynomials-0.2.txt

> o http://www.sagemath.org/packages/standard/elliptic_curves-0.1.txt

> o http://www.sagemath.org/packages/standard/examples-4.5.2.txt

> o http://www.sagemath.org/packages/standard/extcode-4.5.2.txt

> o http://www.sagemath.org/packages/standard/graphs-20070722.p1.txt

> o http://www.sagemath.org/packages/standard/polytopes_db-20100210.txt

> * extcode: a miscellany. Appears to have Tim's debian subdirectory for

> building the package, jsMath, and tons of other stuff. Most (all?) of

> it is not a problem (jsMath is already in Debian, but which version

> is included in Sage is not clear to me), but some things may require

> finding upstream and building a Debian package. More work needed.

> o http://www.sagemath.org/packages/standard/extcode-4.5.2.txt

> * f2c: Debian (20090411-1+b1) is way newer than Sage (20070816.p2).

> We might need to push Sage to upgrade.

> o http://www.sagemath.org/packages/standard/f2c-20070816.p2.txt

I think we only include f2c because of Scipy.

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

> o http://www.sagemath.org/packages/standard/flintqs-20070817.p5.txt

> * gdmodule. Needs a Debian package.

> o http://www.sagemath.org/packages/standard/gdmodule-0.56.p7.txt

> * opencdk. This ships as part of gnutls. However, sage's fork differs

> quite a bit from the code in gnutls. Do we need a package or is it

> part of gnutls with no work needed? I don't know.

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.

> o http://www.sagemath.org/packages/standard/opencdk-0.6.6.p5.txt

Aug 9, 2010, 9:55:48 PM8/9/10

to debia...@googlegroups.com

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.

*python: pickles is still not included in python so it is unlikely to be

provided by debian:

http://bugs.python.org/issue7689

Note also that python-2.6.5 and over ship this:

http://bugs.python.org/issue7491

This will break some stuff:

http://github.com/cschwan/sage-on-gentoo/issues#issue/1

*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

Francois

Sep 30, 2010, 8:22:18 PM9/30/10

to kamaraju kusumanchi, tab...@mit.edu, Lucas Nussbaum, Rogério Brito, debian-...@lists.debian.org, mryan...@cox.net, Sami Losoi, debia...@googlegroups.com, sage-...@googlegroups.com, kumar....@gmail.com

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.

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.

There are some general issues mentioned on this page:

http://wiki.debconf.org/wiki/Debconf10/Unofficial/Talks/MathematicalSoftware

There was a 10-15 minute discussion on packaging

Sage at DebConf10. Video is here:

http://penta.debconf.org/dc10_schedule/events/557.en.html

At a later talk, David Bremner gave an eloquent

summary of the challenges in packaging Sage in Debian:

http://penta.debconf.org/dc10_schedule/events/604.en.html

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?

--

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 | "Dare to be Naive" -- Bucky Fuller

http://www.CJFearnley.com | http://blog.remoteresponder.net/

Oct 2, 2010, 12:34:20 PM10/2/10

to Giovanni Mascellani, debia...@googlegroups.com, kamaraju kusumanchi, tab...@mit.edu, Lucas Nussbaum, Rogério Brito, debian-...@lists.debian.org, mryan...@cox.net, Sami Losoi, sage-...@googlegroups.com, kumar....@gmail.com

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

> 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

>

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

Scipy in Sage requires this patch:

http://projects.scipy.org/scipy/changeset/5790

So that's two issues not one.

> > It might be helpful to maintain this "list of issues for Sage in Debian"

> > so that it can be edited collectively. Where? How?

>

> I just made a wiki page with the issues you outlined:

>

> http://wiki.debian.org/DebianScience/Sage

Excellent!

> > 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-...@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-...@l.d.o

and debia...@googlegroups.com (since I believe that would be

preferred by some Sage people who do not want to bother with all of

debian-...@l.d.o). Would that satisfy everyone on the (overly broad)

CC list?

Oct 2, 2010, 2:22:11 PM10/2/10

to debian-sage, sage-...@googlegroups.com

Sage currently ships v. 0.6.4 of sympy

(http://www.sagemath.org/packages/standard/sympy-0.6.4.p0.txt).

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)?

(http://www.sagemath.org/packages/standard/sympy-0.6.4.p0.txt).

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)?

Oct 4, 2010, 5:26:39 PM10/4/10

to debia...@googlegroups.com, Giovanni Mascellani, kamaraju kusumanchi, tab...@mit.edu, Lucas Nussbaum, Rogério Brito, debian-...@lists.debian.org, mryan...@cox.net, Sami Losoi, sage-...@googlegroups.com, kumar....@gmail.com

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

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.

Ondrej

Oct 5, 2010, 8:38:08 AM10/5/10

to sage-...@googlegroups.com, debia...@googlegroups.com, Giovanni Mascellani, kamaraju kusumanchi, tab...@mit.edu, Lucas Nussbaum, Rogério Brito, debian-...@lists.debian.org, mryan...@cox.net, Sami Losoi, kumar....@gmail.com

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

>

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

Oct 5, 2010, 5:10:02 PM10/5/10

to debia...@googlegroups.com, sage-...@googlegroups.com

On Sat, Oct 2, 2010 at 11:22 AM, cjfsyntropy <c...@cjfearnley.com> wrote:

> Sage currently ships v. 0.6.4 of sympy

> (http://www.sagemath.org/packages/standard/sympy-0.6.4.p0.txt).

>

> 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)?

> Sage currently ships v. 0.6.4 of sympy

> (http://www.sagemath.org/packages/standard/sympy-0.6.4.p0.txt).

>

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

Thanks,

Ondrej

Reply all

Reply to author

Forward

0 new messages

Search

Clear search

Close search

Google apps

Main menu