[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Sage 5.0 in debian : an incomplete (but beautiful?) overview



Le vendredi 18 mai, Felix Salfelder a écrit:
> Hi Julien.
> 
> On Fri, May 18, 2012 at 09:52:05AM +0200, Julien Puydt wrote:
> > How important is it to switch packages from GMP to MPIR?

<snip>

> if my intuition is right, and nothing (but speed and liberty) depends
> on mpir, i'd stick to gmp for now. once anything works (and somebody
> cares), the switch to mpir should be possible independently.

I love when the conclusion is "let's do nothing" ;-)

> > > - moved flint package to 1.5.2 (locally)
> > 
> > Ah, something I can tell more about : sage uses 1.5.2, but with a
> > few patches, while upstream is up to version 2.3. I'll ask on
> > sage-devel why they don't use 2.3 : if I remember well, 1.5.2 has
> > its own set of Makefiles (which give portability issues), while 2.3
> > uses a configure script (but I don't know how good it is), so it
> > might be worth upgrading in both sage and debian.
> 
> if sage (the software) runs with 2.3 (who can check that?), that would
> be much better.

I don't know if sage runs with 2.3 (and I can hardly check since sage
5.0 doesn't compile here because of gcc 4.7).

Notice that sage has both flint (1.5.2) and flintqs, which is a
"quadratic sieve" program based on flint, which according to
http://trac.sagemath.org/sage_trac/ticket/11792 is now found in flint
itself, and should probably be packaged in the same src:flint package
in debian.

I compiled flint 2.3 on my X86_64 box and ran all tests this morning ;
my ARM box managed to compile it but fails some tests (and is still
running them).

I have those problems to report upstream, so I'll probably use the
occasion to ask if they think this flint (which is a rewrite) is ready
to replace the one in sage. I'll report here later.

> > > - packaged mpir (debian-science git)
> > Good ; when will it go in unstable?
> 
> not working on it right now (see above). maybe somebody else has a use
> for it?

Well, if it isn't useful for the sage packaging effort, I'm not that
interested in it.

> > > - packaged sagenb, sage-scripts (locally)
> > 
> > Do they 'work'?
> hard to tell. sagenb is just a python library, sage (the
> python-library) imports it before it segfaults. so at least the
> packaging 'works'.
> 
> sage-script is a set of python fragments that need to be freed from
> the SAGE_* variables (which won't make much sense on debian). i did
> this to the interactive shell ("sage") and fixed sage-gdb. sage-test
> would have been the next i'd like to get running...

Ah, yes, the environment variables. Indeed I expect debian/patches/
directories will be quite full for all sage-native spkg...

> > > - polybori 0.8.0 (pushed to debian-science git, working but
> > > incomplete)
> > 
> > How incomplete is it?
> it builds. probably incomplete copyright and the like. don't we need
> 0.8.1 for sage?

Well, there are two good reasons to package at least 0.8.1 :

- that's what sage 5.0 has ;

- according to http://trac.sagemath.org/sage_trac/ticket/12655, that is
  the first version which doesn't make gcc 4.7 choke, and gcc 4.7 is
  what I have on my unstable :-)

> > > - singular is half way done (debian-science git)
> > 
> > Yes, Bernhard(brl) pointed me to it to try, but it doesn't compile
> > here -- I reported him the result already.
> Cc me, i might be able to fix the simple things.

I'll forward you my report.

> > > - liblcalc-dev 0.0.20090723-1 (draft, locally)
> > 
> > I never looked at it more than "current debian not suitable for
> > sage" ; if it isn't just a case of adding a description of
> > libcalc-dev to control and a libcalc-dev.install.
> 
> thats about what i did (locally).

Ok.

> > then I guess it's not using autotools, is it?
> 
> static Makefile. debian/rules just sets some flags. looks a bit
> fragile.

Yes, but if upstream is like this...

> > I'd also like to clarify what they do with boost in sage : it seems
> > they took their sources not from upstream, but from what is in
> > polybori...  and they seem to have problems with it (sic).
> 
> i'm not expecting boost problems on debian, but good to know...

Well, since they supposedly (according to the explicit deps) only use
boost for polybori, I hope everything will just be alright too.

Snark on #debian-science


Reply to: