François Bissey | 5 Dec 2009 10:09
Picon
Picon

sage on gentoo: an experimental overlay take 2

For some reason it didn't go the first time so here it is again:

Hi all,

This is a bit of an announcement. It won't be a mystery to people
who hang on irc or watch bug#201321.
Christopher Schawn (gnuke) started an overlay to develop a split version
of sage for Gentoo and I joined forces with him as the person having
done the latest attempt.

So the overlay lives on github and can be inspected here:
http://github.com/cschwan/sage-on-gentoo
and you can pull it with:
git clone git://github.com/cschwan/sage-on-gentoo.git
A package.keyword list is also provided in the overlay.
We will probably create a set as well in the near future.

We plan to make the overlay self sufficient. That is someone
should only need this overlay and the standard tree to build portage.
I will sync stuff back to science when it is ready but for now we don't
want overlay dependency hell.

Once we reach a rather stable stage we may look at making the science 
overlay a dependency for this overlay (provided it can be done - I remember 
hearing stuff but I don't know if it has been implemented).

Testers and advice welcome. We currently a partially split sage that seems
to more or less on x86 and amd64. But more work is needed on amd64
in particular.

(Continue reading)

François Bissey | 6 Dec 2009 09:53
Picon
Picon

should we have virtual/clapack

Hi,

We have virtuals for blas, cblas and lapack. At the moment there is only
one package with a clapack implementation in the tree and one in the 
science overlay. These two are the only one I could find with a quick search.

With the sage development there is at least one package that depends
on a clapack implementations. So should we plan for a virtual/clapack?

Francois

Justin | 7 Dec 2009 16:42

Re: should we have virtual/clapack

François Bissey wrote:
> Hi,
> 
> We have virtuals for blas, cblas and lapack. At the moment there is only
> one package with a clapack implementation in the tree and one in the 
> science overlay. These two are the only one I could find with a quick search.
> 
> With the sage development there is at least one package that depends
> on a clapack implementations. So should we plan for a virtual/clapack?
> 
> Francois
> 

Just find out whether there more packages which can provide an equal
implementation for clapack. If so a virtual package would make sense,
but only then.

Sébastien Fabbro | 7 Dec 2009 18:29
Picon
Favicon

Re: should we have virtual/clapack

On Sunday 06 December, François Bissey wrote:

> on a clapack implementations. So should we plan for a virtual/clapack?

I don't know of an official ANSI/ISO C API for clapack.
The netlib clapack implementation is a f2c'ed conversion from
Fortran lapack. There is another clapack in ATLAS, which has a
different API, and does not cover all LAPACK routines.

--
Sebastien

François Bissey | 7 Dec 2009 21:24
Picon
Picon

Re: should we have virtual/clapack

On Tue, 08 Dec 2009 06:29:32 Sébastien Fabbro wrote:
> On Sunday 06 December, François Bissey wrote:
> > on a clapack implementations. So should we plan for a virtual/clapack?
> 
> I don't know of an official ANSI/ISO C API for clapack.
> The netlib clapack implementation is a f2c'ed conversion from
> Fortran lapack. There is another clapack in ATLAS, which has a
> different API, and does not cover all LAPACK routines.
> 
They are the only 2 that I have seen. It is interesting that there
is no official C API. I am guessing linbox is actually expecting ATLAS
since there are different API we will put that.
That's an important clarification.

Thanks,
Francois 

François Bissey | 14 Dec 2009 12:35
Picon
Picon

new paraview ebuild for testing

Hi,

I wanted to test the OverView application shipped with paraview so I ended
up touching the ebuild. As a side effect I ported it to the cmake-utils eclass
found out why a number of plugin didn't configure or compile (all related
to OverView actually). Did a bit of cleaning on the dependencies and 
requirements. The ebuild is full of comment and I can provide more if needed.
I am sure paraview as gotten faster on my computer as a result but I am not
entirely sure which bit did that.
So it install OverView, manually because there isn't an install target for it,
and it seems to work as far as it goes. The install procedure is raw.
Comments and suggestions welcome.

Francois

Oliver Borm | 14 Dec 2009 13:42
Picon

Re: new paraview ebuild for testing

Hello François,

thanks for this work, but as the paraview ebuild in the portage tree is
not yet stable, I have hardmasked your ebuild in the science overlay.
Otherwise everybody who does use the science overlay will automatically
be a beta tester of your ebuild.

Oliver

François Bissey schrieb:
> Hi,
>
> I wanted to test the OverView application shipped with paraview so I ended
> up touching the ebuild. As a side effect I ported it to the cmake-utils eclass
> found out why a number of plugin didn't configure or compile (all related
> to OverView actually). Did a bit of cleaning on the dependencies and 
> requirements. The ebuild is full of comment and I can provide more if needed.
> I am sure paraview as gotten faster on my computer as a result but I am not
> entirely sure which bit did that.
> So it install OverView, manually because there isn't an install target for it,
> and it seems to work as far as it goes. The install procedure is raw.
> Comments and suggestions welcome.
>
> Francois
>
>   

François Bissey | 14 Dec 2009 21:21
Picon
Picon

Re: new paraview ebuild for testing

On Tue, 15 Dec 2009 01:42:07 Oliver Borm wrote:
> Hello François,
> 
> thanks for this work, but as the paraview ebuild in the portage tree is
> not yet stable, I have hardmasked your ebuild in the science overlay.
> Otherwise everybody who does use the science overlay will automatically
> be a beta tester of your ebuild.
> 
I hadn't thought of that. Thanks for doing it.

Francois

François Bissey | 16 Dec 2009 04:30
Picon
Picon

Re: new paraview ebuild for testing

Updated the ebuild a little bit. If anyone had tried the cg flag
it should now work. OverView definitely works at this stage.
What to do with it is another question.

Francois


Gmane