Linbox in Debian
Timothy G Abbott
I've packaged LinBox for Debian. My goal is to get LinBox and SAGE into the
Debian lenny release, which will be frozen in 4 or 5 weeks (so ideally the
package should be ready in 2-3 weeks).
I have a draft package for LinBox available in the repository described at
<http://wiki.sagemath.org/DebianSAGE> (only the amd64 binary is up-to-date).
My package is based on the SAGE 3.0.1 sources, which seem to be very slightly
modified from upstream 1.1.5.
There are some problems with the current package that need to be fixed and I
think would be best fixed upstream.
One problem is that both givaro and linbox try to install
/usr/include/gmp++/gmp++_int.inl and friends, but the versions they install are
slightly different. Obviously, one can only install one version of these
headers there at a time; I'd prefer if LinBox and Givaro were to merge their
gmp++ headers. My current solution is to only include these headers in the
givaro package, but I'm not sure this results in correct behavior.
A trivial thing is that linbox-config should have a man page. You can generate
one automatically using
help2man -n "tool for linking against LinBox" linbox-config
Obviously, I can do this myself in the Debian package, but I think there is
interest in packaging LinBox for other distributions, and they'll probably want
the man page too, so it'd be best for this automation to happen in upstream
LinBox.
Finally, I'd really like to see the SAGE linbox wrapper included in the linbox
package, since I'd prefer to not create a linbox-wrapper source package in
Debian.
If it's likely that a LinBox release in the next week or two could fix some or
all of these problems, I'd greatly appreciate it. Thanks,
-Tim Abbott
(resent because apparently linbox-devel is a members-only list)
Clement Pernet
First, thank you Tim (and Michael) for the work you've done on porting
into Debian.
>
> There are some problems with the current package that need to be fixed and I
> think would be best fixed upstream.
>
> One problem is that both givaro and linbox try to install
> /usr/include/gmp++/gmp++_int.inl and friends, but the versions they install are
> slightly different. Obviously, one can only install one version of these
> headers there at a time; I'd prefer if LinBox and Givaro were to merge their
> gmp++ headers. My current solution is to only include these headers in the
> givaro package, but I'm not sure this results in correct behavior.
This issue was raised several times by Mabshoff, and the only diff I get
from the 2 versions is in gmp++.h, whith the different defines of Givaro
and LinBox.
I am going to uniformize it, but as was mentionned in the later
discussion, I don't see why this problem shows up when --with-givaro is
enabled.
>
> A trivial thing is that linbox-config should have a man page. You can generate
> one automatically using
>
> help2man -n "tool for linking against LinBox" linbox-config
>
> Obviously, I can do this myself in the Debian package, but I think there is
> interest in packaging LinBox for other distributions, and they'll probably want
> the man page too, so it'd be best for this automation to happen in upstream
> LinBox.
Will do.
>
> Finally, I'd really like to see the SAGE linbox wrapper included in the linbox
> package, since I'd prefer to not create a linbox-wrapper source package in
> Debian.
>
> If it's likely that a LinBox release in the next week or two could fix some or
> all of these problems, I'd greatly appreciate it. Thanks,
Ok, that was planned for release 2.0, but since it may be a too long
term, and it looks like a blocker for you, I'll commit to release 1.1.6
with the sage interface within 2 weeks or so.
Cheers,
Clément
David Saunders
givaro and linbox to UNinstall cleanly. I suppose it could be "last one
out the door, take gmp++ with you." In other words linbox's uninstall
should look for the presence of givaro and uninstall gmp++ only if
givaro is not there. This is not very satisfactory and it is easy to
imagine missteps, including removal of gmp++ when it shouldn't be.
How about making givaro a _required_ package for linbox? Then Givaro
can be responsible for gmp++ (and for the very useful Zech log stuff).
What's the downside? Let's do it.
If not that, frankly, I would recommend givaro and linbox use separate
gmp++ wrappers. Good citizens don't install little bits in ../include/
and ../lib/ and then just abandon them there.
-dave
mabshoff
Hi,
> We should clean up this gmp++ business in a way that makes it easy for
> givaro and linbox to UNinstall cleanly.
people rather surprised that uninstalling Linbox breaks Givaro.
> I suppose it could be "last one
> out the door, take gmp++ with you." In other words linbox's uninstall
> should look for the presence of givaro and uninstall gmp++ only if
> givaro is not there. This is not very satisfactory and it is easy to
> imagine missteps, including removal of gmp++ when it shouldn't be.
>
> How about making givaro a _required_ package for linbox? Then Givaro
> can be responsible for gmp++ (and for the very useful Zech log stuff).
> What's the downside? Let's do it.
> If not that, frankly, I would recommend givaro and linbox use separate
> gmp++ wrappers. Good citizens don't install little bits in ../include/
> and ../lib/ and then just abandon them there.
>
> -dave
>
> > Ok, that was planned for release 2.0, but since it may be a too long
> > term, and it looks like a blocker for you, I'll commit to release 1.1.6
> > with the sage interface within 2 weeks or so.
Linbox.spkg
http://trac.sagemath.org/sage_trac/attachment/ticket/2931/linbox-1.1.5-gcc-4.3.patch
These are the changes that Tim probably noticed. We are also shipping
the latest svn, so getting 1.1.6 out might be a good thing. The above
patch consists of two logical changes:
a) uncommenting of a bunch of template classes that gcc 4.3 complained
about when compiling Sage's linbox_wrapper. With that patch applied
the linbox_wrapper compiles and valgrinds clean, but there are now
some new issues that cause a bunch of Linbox's test cases to segfault
at exit due to some gmp++ deallocation issues. I never took the time
to clean this up, so it was never submitted.
b) adding a missing "#include <cstring>" in linbox-1.1.5p1/linbox/
linbox/util/error.h - that one should be fairly non-controversial to
apply.
> > Cheers,
>
> > Clément
Cheers,
Michael
Clement Pernet
>> How about making givaro a _required_ package for linbox? Then Givaro
>> can be responsible for gmp++ (and for the very useful Zech log stuff).
>> What's the downside? Let's do it.
This gmp++ conflict is the last step before releasing 1.1.6 and the
debianization.
Dave suggested to get rid of the linbox gmp++ and only use givaro's
gmp++ thus making givaro a mandatory package for linbox.
Does anyone object to this decision?
If not, we are going to do it these coming days.
> FYI: We currently have the following patch applied to the Sage
> Linbox.spkg
>
> http://trac.sagemath.org/sage_trac/attachment/ticket/2931/linbox-1.1.5-gcc-4.3.patch
>
patch is now obsolete due to recent changes upstream.
> a) uncommenting of a bunch of template classes that gcc 4.3 complained
> about when compiling Sage's linbox_wrapper. With that patch applied
> the linbox_wrapper compiles and valgrinds clean, but there are now
> some new issues that cause a bunch of Linbox's test cases to segfault
> at exit due to some gmp++ deallocation issues. I never took the time
> to clean this up, so it was never submitted.
>
already done plus more gcc-4.3 fixes. gcc-4.3 seems to be well supported
now.
> b) adding a missing "#include <cstring>" in linbox-1.1.5p1/linbox/
> linbox/util/error.h - that one should be fairly non-controversial to
> apply.
done.
Clément
Clement Pernet
The linbox 1.1.6 release candidate #0 is almost ready:
* I shaved out the gmp++ of LinBox, and made Givaro a mandatory package,
so that LinBox uses Givaro gmp++
* Merged in the sage wrapper in the interface directory
* Fixed the remaining gcc-4.3 warnings.
* fixed other bugs
Tim, I just need you to tell me what should I do with the man page
generated by the help2man command that you mentionned.
Do you need it to be a file in the linbox-1.1.6.tar.gz ?
Which naming convention shall we use for this file?
Once we fix this minor question, I'll commit my changes upstream, put
1.1.6rc0 online and continue to test/valgrind it on different architectures.
Cheers,
Clément
Timothy G Abbott
and add code to Makefile.am to install it as $mandir/man1/linbox-config.1.
I think the automake way to do this is to add to Makefile.am
man1_MANS = linbox-config.1
You'll probably want to set linbox-config.1 to be automatically
regenerated in doc/ (using the help2man command) if help2man is available
and automatically deleted at clean time, so that it stays up-to-date over
time.
By the way, I assume you've fixed this already, but my package current
patches doc/Makefile.am to remove the line:
cp ../HACKING linbox-html
-Tim Abbott
Dave Saunders
solutions directory. Toward that, I've added a page to the trak site on
LinBox2.0, namely http://linalg.org/projects/linalg/wiki/SolverDesign
I've also messed with the
http://linalg.org/projects/linalg/wiki/MatrixDesign.
Please take a look at these and edit/embellish/ comment them. I'd like
them to clean them up in a way that has a consensus behind it by the end
of September. That means to settle on one or another option where there
are conflicting statements and to remove some of the
stream-of-consciousness blather I've put in there.
There are really two things that distinguish our Matrix notions from our
Blackboxes, and I think we are a little confused about these two
things. They are that (1) matrix entries are accessible in constant
time and (2) eliminations of some kind can be done on them. These are
related but distinct points about them. I'm growing more and more to
believe that our generic view of them is too low level (row operations)
and that the valuable distinguishing characteristic of a sparse or dense
matrix is being able to do an LQUP on it.
Cheers, -dave