Re: please schedule a rebuild for sagemath on alpha architecture
CJ Fearnley
> 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
kamaraju kusumanchi
> 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.
kamaraju kusumanchi
>
> 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
William Stein
> 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
Tim Abbott
> 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.
>
>
William Stein
I was just thinking about the sage core Python/Cython library. E.g.,
what gets built by
sage -ba
William
CJ Fearnley
> 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
William Stein
> 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
François Bissey
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
CJ Fearnley
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/
CJ Fearnley
> 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?
cjfsyntropy
(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)?
Ondrej Certik
> 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
CJ Fearnley
> 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.
Ondrej Certik
> 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