Re: Sage 5.0 in debian : an incomplete (but beautiful?) overview
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?
the short answer is probably "no", because mpir is not needed at all.
> I mean, is it needed.
i did this mostly, because the segfault i got was somewhere in between
libsingular and libgmp. i guessed switching to mpir that sage (the
distribution) uses, might help. (it didnt).
> does it bring anything?
they claim that mpir is faster and more liberal (something about LGPL
iirc).
> I hate changes to upstream which aren't limited to packaging needs.
> (Perhaps because I'm upstream in a project and had bad experiences
> with packages which made stupid things...)
thats not an issue: the mpir switch is package related only. just "link
library again after s/-lgmp/-lmpir/, call it liblibrary-mpir.so and put
the results into liblibrary-mpir(-dev)."
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.
> > - 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.
> > - 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?
> > - 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...
> > - 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?
> > - 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.
> > - 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).
> then I guess it's not using autotools, is it?
static Makefile. debian/rules just sets some flags. looks a bit fragile.
> I'll start with having a look at flint in sage and upstream : I'd
> rather see debian&sage follow upstream, than have debian follow sage
> which minds its own business without upstream.
fine.
> 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...
regards
felix
Reply to: