Nabble - debian-science

Bug#561090: RFP: cba -- continuous beam analysis

2009-12-13T21:05:51Z

Package: wnpp
Severity: wishlist

* Package name : cba
Version : 0.3.4
Upstream Author : pierrot <idf.dresden@...>
* URL : http://mentors.debian.net/debian/pool/main/c/cba
* License : GPL
Programming Lang: C++
Description : continuous beam analysis

calculates member forces and support reactions of a continuous
beam

-- System Information:
Debian Release: 4.0
APT prefers oldstable
APT policy: (500, 'oldstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-486
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)

--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: pkg-escience [Was: Re: Torque in Debian?]

2009-12-11T03:00:07Z

On 11/12/2009 11:44, Steffen Moeller wrote:

> Sylvestre Ledru wrote:
>
>> Le jeudi 10 décembre 2009 à 16:50 +0100, Morten Kjeldgaard a écrit :
>>
>>> We are now co-maintaining the package in Debian's pkg-escience team
>>> [0]. The version that is currently in Ubuntu is in one of the
>>> branches. Steffen and I had independently packaged Torque, but our
>>> efforts are now essentially merged in trunk.
>>>
>> Not related to Torque but just for curiosity, why did you call this team
>> pkg-escience ?
>>
> There was a time when I was seriously interested to have Taverna packaged
> for Debian. And Taverna is one of the icons of the eScience "movement". It
> is on alioth such that everyone interested can contribute.
>
> The packaging of Taverna is however difficult, I ran into bugs when
> substituting the distributed .jar files with my self-compiled ones, and
> nobody could suggest what version of the respective .jars to take. It would
> probably help the community to get this all sorted out, I have hence not
> removed those bits from the server, but it will probably wait for my
> retirement to happen.
>
> Since then, the pkg-escience project became a "let's not disturb anyone"
> kind of meeting place for various technical applications.
>
>

OK, thanks for the explanation.
I understand why you picked up this name but it creates an important
confusion with Debian Science... We already have a confusion between
Debian Science and pkg-scicomp (we are working to solve this issue), I
don't see the point of adding a third.

You could also use Debian science for your various technical
applications without disturbing anyone (we are nice people). It remains
one of the goal of Debian Science...

Sylvestre

--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Torque in Debian?

2009-12-11T02:58:18Z

Hello,

Morten Kjeldgaard wrote:

>> I seem to recall that someone once mentioned packaging of Morten's Torque
>> packages from Ubuntu. I also seem to recall Steffen saying that he was in
>> contact with Morten. Based on quick search of my mail folder I can't
>> find
>> traces of either. Could someone kindly refresh my memory?
>
> We are now co-maintaining the package in Debian's pkg-escience team [0].
> The version that is currently in Ubuntu is in one of the branches.
> Steffen and I had independently packaged Torque, but our efforts are now
> essentially merged in trunk.
>
> It is my intention to upload the merged version to Ubuntu in the current
> development cycle (Lucid). There is a single bug in LP that can
> hopefully be closed along with that.

The new 2.4 version of Torque has seen its official praise now, indeed. You
may forgive my comment indicating that since gridengine is in Debian
already and accepted as Free, my interest in Torque has considerably been
reduced, though. We are just migrating to gridengine here.

>> [ Google sees traces of informal packaging of Torque on non-Debian
>> repos and
>> prior debian-legal discussion -- did that ever progress beyond the
>> earlier
>> "Nope" ? ]
>
> Oh, that. Yes it is a complicated situation, which doesn't get any
> better by the fact that the Torque maintainers don't give a d*mn about
> license issues. AFAIK several people have emailed them about it and they
> never answer.

They do answer, they just answer that they don't answer, suggesting not to
package it when we don't like it. I met upstream at their booth at the
supercomputing conference in Hamburg and had a few emails with them
afterwards. Without a clear go-ahead that the software shall be considered
as Free, it should go to the non-free section IMHO.

> The current Torque effort is the result of several forked
> projects the history of which are pretty much lost in the annals... in
> my memory at least :-)
>
> In Ubuntu, the torque package resides in "Multiverse" which corresponds
> to the "non-free" section of Debian. Torque has it's own peculiar
> license which tends to make the archive-admins nervous. It is my
> conviction however, that Torque in practice is FOSS perhaps even FLOSS.

I agree. This is why I still think that the package should appear after all.

Concerning the packaging, it is ready to be uploaded IMO. Actually, it was
only a comment on the free vs non-free issue in a favour of free that let
me retract a previous upload of 2.3 to Debian. I solidified my stance
towards non-free by now but was too busy since then to bother about
reuploading. The installation of the debconf-savvy gridengine-exec is
lovely in my mind. Morten views this all a bit differently and prefers a
non-communicating installation, which is also fine. He is the boss :)

Morten, whenever you want me to upload 2.4, tell me.

Many greetings

Steffen

--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: pkg-escience [Was: Re: Torque in Debian?]

2009-12-11T02:44:42Z

Sylvestre Ledru wrote:

> Le jeudi 10 décembre 2009 à 16:50 +0100, Morten Kjeldgaard a écrit :
>> Hi Dirk,
>>
>>> I seem to recall that someone once mentioned packaging of Morten's
>>> Torque
>>> packages from Ubuntu. I also seem to recall Steffen saying that he
>>> was in
>>> contact with Morten. Based on quick search of my mail folder I
>>> can't find
>>> traces of either. Could someone kindly refresh my memory?
>> We are now co-maintaining the package in Debian's pkg-escience team
>> [0]. The version that is currently in Ubuntu is in one of the
>> branches. Steffen and I had independently packaged Torque, but our
>> efforts are now essentially merged in trunk.
> Not related to Torque but just for curiosity, why did you call this team
> pkg-escience ?

There was a time when I was seriously interested to have Taverna packaged
for Debian. And Taverna is one of the icons of the eScience "movement". It
is on alioth such that everyone interested can contribute.

The packaging of Taverna is however difficult, I ran into bugs when
substituting the distributed .jar files with my self-compiled ones, and
nobody could suggest what version of the respective .jars to take. It would
probably help the community to get this all sorted out, I have hence not
removed those bits from the server, but it will probably wait for my
retirement to happen.

Since then, the pkg-escience project became a "let's not disturb anyone"
kind of meeting place for various technical applications.

Steffen

--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

pkg-escience [Was: Re: Torque in Debian?]

2009-12-10T09:37:23Z

Le jeudi 10 décembre 2009 à 16:50 +0100, Morten Kjeldgaard a écrit :

> Hi Dirk,
>
> > I seem to recall that someone once mentioned packaging of Morten's
> > Torque
> > packages from Ubuntu. I also seem to recall Steffen saying that he
> > was in
> > contact with Morten. Based on quick search of my mail folder I
> > can't find
> > traces of either. Could someone kindly refresh my memory?
>
> We are now co-maintaining the package in Debian's pkg-escience team
> [0]. The version that is currently in Ubuntu is in one of the
> branches. Steffen and I had independently packaged Torque, but our
> efforts are now essentially merged in trunk.

Not related to Torque but just for curiosity, why did you call this team
pkg-escience ?

Sylvestre

--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#560347: RFP: ncl -- Nexus Class Library

2009-12-10T08:35:39Z

Package: wnpp
Severity: wishlist

* Package name : ncl (Nexus Class Library)
Version : 2.1.08 (dated 2009-11-30)
Upstream Author : Paul O. Lewis
* URL or Web page : http://hydrodictyon.eeb.uconn.edu/ncl/
* License : GPL-2
Description : Nexus Class Library
The NEXUS Class Library (NCL) is an integrated collection of C++ classes
designed to allow the user to quickly write a program that reads
NEXUS-formatted data files. It also allows easy extension of the NEXUS format
to include new blocks of your own design.
.
The NEXUS data file format was specified in the publication cited
below. Please read this paper for further information about the format
specification itself; the documentation for the NCL does not attempt to
explain the structure of a NEXUS data file.
Maddison, D. R., D. L. Swofford, and Wayne P. Maddison. 1997. NEXUS: an
extensible file format for systematic information. Systematic Biology 46(4):
590-621.
.
The basic goal of the NCL is to provide a relatively easy way to endow a
C++ program with the ability to read NEXUS data files. The steps necessary
to use the NCL to create a bare-bones program that can read a NEXUS data
file are simple and few, and it is hoped that the availability of this
class library will encourage the use of the NEXUS format. This will in
turn encourage consistency in how programs read NEXUS files and how
programs respond to errors in data files.
.
There are a large number of special data file formats in use. This places
an extra burden on the end user, who must deal with an increasing number
of file formats all differing in a number of ways. To convert one's data
file to another file format often involves manual manipulation of the
data, an activity that is inherently dangerous and probably has resulted
in the corruption of many data files. At the very least, the large number
of formats in existance has led to a proliferation of data file
variants. With many copies of a given data file on a hard disk, each
formatted differently for various analysis programs, it becomes very easy
to change one (say, correct a datum found to be in error) and then fail to
correct the other versions. The NEXUS file format provides a means for
keeping one master copy of the data and using it with several programs
without modification. The NCL provides a means for encouraging programmers
to use the NEXUS file format in future programs they write.

I could use that for some R packaging (of 'phylobase'), but as I don't use
this directly I don't really want to be / should be the maintainer.

Any biologists in the readership who would like to work on this?

Dirk

--
Three out of two people have difficulties with fractions.

--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Torque in Debian?

2009-12-10T07:50:21Z

Hi Dirk,

> I seem to recall that someone once mentioned packaging of Morten's
> Torque
> packages from Ubuntu. I also seem to recall Steffen saying that he
> was in
> contact with Morten. Based on quick search of my mail folder I
> can't find
> traces of either. Could someone kindly refresh my memory?

We are now co-maintaining the package in Debian's pkg-escience team
[0]. The version that is currently in Ubuntu is in one of the
branches. Steffen and I had independently packaged Torque, but our
efforts are now essentially merged in trunk.

It is my intention to upload the merged version to Ubuntu in the
current development cycle (Lucid). There is a single bug in LP that
can hopefully be closed along with that.

> [ Google sees traces of informal packaging of Torque on non-Debian
> repos and
> prior debian-legal discussion -- did that ever progress beyond the
> earlier
> "Nope" ? ]

Oh, that. Yes it is a complicated situation, which doesn't get any
better by the fact that the Torque maintainers don't give a d*mn about
license issues. AFAIK several people have emailed them about it and
they never answer. The current Torque effort is the result of several
forked projects the history of which are pretty much lost in the
annals... in my memory at least :-)

In Ubuntu, the torque package resides in "Multiverse" which
corresponds to the "non-free" section of Debian. Torque has it's own
peculiar license which tends to make the archive-admins nervous. It is
my conviction however, that Torque in practice is FOSS perhaps even
FLOSS.

Cheers,
Morten

[0] http://svn.debian.org/viewsvn/pkg-escience/torque/

--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Retiring from Debian

2009-12-09T17:46:18Z

Hi Kev,

You really did a great job. I came to your webpages on p.d.o when
googling "geant4 debian" and read about your opinion towards the chaos
of scientific packages.

Best wishes for your new life!

Yours,
--
XU Benda
Research Center for Neutrino Science
Department of Physics
Tohoku University
JAPAN

http://www.awa.tohoku.ac.jp/~benda

--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Torque in Debian?

2009-12-09T15:37:54Z

Hi,

On Wed, Dec 09, 2009 at 05:16:12PM -0600, Dirk Eddelbuettel wrote:
> I seem to recall that someone once mentioned packaging of Morten's Torque
> packages from Ubuntu.

They are in multiverse now, for what's it worth.

> I also seem to recall Steffen saying that he was in contact with
> Morten. Based on quick search of my mail folder I can't find traces
> of either. Could someone kindly refresh my memory?

We discussed it on this list in the thread "simple batch queue system?"
in July or so.

I think the last news was that Steffen asked ftp-master whether the
license is fine, not sure he ever got an answer. If not, it is really a
tough call I guess, maybe somebody should just upload it and see what
happens.

Michael

--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Torque in Debian?

2009-12-09T15:16:12Z

I seem to recall that someone once mentioned packaging of Morten's Torque
packages from Ubuntu. I also seem to recall Steffen saying that he was in
contact with Morten. Based on quick search of my mail folder I can't find
traces of either. Could someone kindly refresh my memory?

[ Google sees traces of informal packaging of Torque on non-Debian repos and
prior debian-legal discussion -- did that ever progress beyond the earlier
"Nope" ? ]

Dirk

--
Three out of two people have difficulties with fractions.

--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Retiring from Debian

2009-12-09T10:17:48Z

On Tue, Dec 08, 2009 at 05:40:44PM -0800, Kevin B. McCarty wrote:
> Maybe ... there are serious licensing obstacles to making official
> packages of most of my unofficial stuff, unfortunately.

Well, but by any means: Having the packaging stuff in a Debian Science
SVN - thus in a location where the Debian Science team and users might
expect such stuff would be an advantage in my eyes - even if it only
builds inofficial packages.

Kind regards

Andreas.

--
http://fam-tille.de

--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

ROOT in Sid uninstallable

2009-12-09T01:55:33Z

Hello guys,

>From the page

http://packages.qa.debian.org/r/root-system.html,

it seems that ROOT can't be build on the architectures other than amd64
and ia64.

What's the problem and what's the current status?

Yours,
--
XU Benda
Research Center for Neutrino Science
Department of Physics
Tohoku University
JAPAN

http://www.awa.tohoku.ac.jp/~benda

--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Retiring from Debian

2009-12-08T17:40:44Z

On Tue, Dec 8, 2009 at 2:35 PM, Andreas Tille <andreas@...> wrote:

> On Tue, Dec 08, 2009 at 02:18:27PM -0500, Brett Viren wrote:
>> "Kevin B. McCarty" <kmccarty@...> writes:
>>
>> > With best wishes to the project,
>>
>> My thanks go out for your good work. Having Geant4 in Debian packages
>> is very useful.
>
> As far as I understood Kevin we deo *not* have Geant4 in Debian because
> he maintains an unofficial repository under people.d.o.

Right, although the Geant4 packages (due partly to size) are in a
separate location, under
http://lcg-heppkg.web.cern.ch/lcg-heppkg/debian/ . (I'm pretty sure
Brett is aware of it and meant that it's useful to have Geant4
available in .deb format even unofficially. I suspect anyone who's
gone through that software's build process by hand agrees.)

> Somebody should
> care for taking over this stuff in an apropriate Vcs (either SVN or Git)
> of Debian Science and try to form a team which cares for these packages.

Maybe ... there are serious licensing obstacles to making official
packages of most of my unofficial stuff, unfortunately.

best regards,

--
Kevin B. McCarty <kmccarty@...>
WWW: http://www.starplot.org/
WWW: http://people.debian.org/~kmccarty/
GPG: public key ID 4F83C751

--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Retiring from Debian

2009-12-08T14:35:32Z

On Tue, Dec 08, 2009 at 02:18:27PM -0500, Brett Viren wrote:
> "Kevin B. McCarty" <kmccarty@...> writes:
>
> > With best wishes to the project,
>
> My thanks go out for your good work. Having Geant4 in Debian packages
> is very useful.

As far as I understood Kevin we deo *not* have Geant4 in Debian because
he maintains an unofficial repository under people.d.o. Somebody should
care for taking over this stuff in an apropriate Vcs (either SVN or Git)
of Debian Science and try to form a team which cares for these packages.

Kind regards

Andreas.

--
http://fam-tille.de

--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Retiring from Debian

2009-12-08T11:18:27Z

"Kevin B. McCarty" <kmccarty@...> writes:

> With best wishes to the project,

My thanks go out for your good work. Having Geant4 in Debian packages
is very useful.

-Brett.

--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Retiring from Debian

2009-12-08T09:58:59Z

Hi all,

I am retiring from Debian due to a probably-permanent lack of time for
Debian work. While having a new baby last month certainly didn't help
with this, it did force me to admit it to myself ;-)

My official packages are all orphaned as per Developers Ref. 3.7 &
5.9.4. Regarding unofficial packages or my people.debian.org/~kmccarty/
web pages, anyone who wants to take them over, please contact Axel
Naumann <Axel.Naumann@...> for Geant4, or me for anything else.

After my Debian email forwarding expires I will be reachable at
kmccarty@... .

With best wishes to the project,

--
Kevin B. McCarty <kmccarty@...>
WWW: http://www.starplot.org/
WWW: http://people.debian.org/~kmccarty/
GPG: public key ID 4F83C751

signature.asc (268 bytes) Download Attachment

Re: Bug#509296: Preparation for VTK 5.4

2009-12-07T02:18:14Z

[CCing debian-science]

On Mon, Dec 7, 2009 at 10:42 AM, Mathieu Malaterre
<mathieu.malaterre@...> wrote:
>> Bug 558716 is really the only thing that worries me now. Perhaps the
>> best solution is to only enable VTK_USE_MPI on architectures that use
>> openmpi.
>
> ParaView has been building fine AFAIK. I did not check but I am pretty
> sure MPI option is ON.

Ok. I did check paraview is being build with -DPARAVIEW_USE_MPI:ON

And again in the CMakeListstxt:

SET(PARAVIEW_USE_MPI OFF CACHE BOOL "Build ParaView with MPI support")
SET(VTK_USE_MPI ${PARAVIEW_USE_MPI} CACHE INTERNAL "Build VTK with MPI
support" FORCE)

So I believe VTK should build with VTK_USE_MPI. Could anyone from
debian-science working on paraview double check this thing ?

I would try this option with VTK 5.4 and see if this is not just an
issue with VTK 5.2

HTH
--
Mathieu

--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: MPI implementations in squeeze

2009-12-03T19:15:33Z

On Tue, 2009-12-01 at 11:31 +0100, Manuel Prinz wrote:

I'll probably keep it simple and just build once against
mpi-default-dev. If users have a strong need for other MPIs then they
can file a bug request.

Thanks all for the tips, hopefully won't be too tricky to get gerris
mpi-packaged.

Drew

--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: MPI implementations in squeeze

2009-12-01T16:45:13Z

On Wed, 2009-12-02 at 00:48 +0100, Manuel Prinz wrote:

> Am Dienstag, den 01.12.2009, 21:20 +0100 schrieb Lucas Nussbaum:
> > While I would be fine with that, there are other possible plans:
> > (2) use MPICH2 as default everywhere (it is supported on all release
> > archs). Clearly, the package didn't receive a lot of testing yet,
> > but this is likely to be only a temporary problem.
>
> I do not care that much. We chose Open MPI because it was the most
> mature implementation at that time. I do not know much about MPICH2, and
> am open to use MPICH2 as the default. I'd like to go with Open MPI, but
> as one of the Open MPI maintainers in Debian, my view is biased.

As a data point from the "real world", the Australian Supercomputing
Facility currently offers Open MPI but not MPICH2 [1]. Mind you the
clusters are just x86_64 so no arcane architecture.

They will install new software if users request and justify the need, so
they might potentially build MPICH2 if someone asked, though I imagine
they'd first strongly encourage the user to try Open MPI first.

[1]
http://nf.nci.org.au/facilities/software/software.php?software=MPI&site=ANU&from_site=ANU

--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: MPI implementations in squeeze

2009-12-01T15:48:47Z

Am Dienstag, den 01.12.2009, 21:20 +0100 schrieb Lucas Nussbaum:
> So the plan would be to use OpenMPI on all architectures where it is
> supported, and MPICH2 on the other ones, using mpi-default?

Yes.

> What do we do with LAM and mpich1? Target their removal for squeeze?

No, I would like to keep them for another release cycle so our users
have time to migrate. Removing all build-depends to them would be the
goal for squeeze, and a note in the release notes might be reasonable.
The removal could easily be done after squeeze.

On the other hand, they are not in the best shape, so this might be a
reason for them to go earlier. But it has been like that for quite a
while now, and a smooth transition might serve our users better. But I
really can't say what our users will prefer. Any input is very welcome!

> While I would be fine with that, there are other possible plans:
> (2) use MPICH2 as default everywhere (it is supported on all release
> archs). Clearly, the package didn't receive a lot of testing yet,
> but this is likely to be only a temporary problem.

I do not care that much. We chose Open MPI because it was the most
mature implementation at that time. I do not know much about MPICH2, and
am open to use MPICH2 as the default. I'd like to go with Open MPI, but
as one of the Open MPI maintainers in Debian, my view is biased. There
are some things that came into my mind:

* We shipped with Open MPI in the last release. This is no strong
argument, as the situation is still messy and we only had one
reasonable choice. I'm for switching if there is a good
technical argument about one over the other. If there isn't, I'd
prefer to stay with it as is.
* Open MPI does not build everywhere but it's well tested on the
platforms where it builds, and shown to work as expected. From
my experience LAM did build everywhere but did not run
everywhere. I do not know about the situation with MPICH2. If
it's functional on all platforms, it might be a good
alternative.
* The next upload of Open MPI will (probably) build on hppa. I
have worked with upstream and other contributors to add support
for other platforms, and we're working on more. For those not
supported, we plan to build using libatomic-ops. I'm not sure
when this will be done but I'm putting quite some efforts into
that so we will have that for squeeze. Also no strong argument,
I know.
* Upstream is very active and supportive. Response time is low and
all patches where included so far. They even coordinated a
release with us. It helped us a lot. Again, might be the same
with MPICH2, I just don't know.

Neither of those are strong arguments. I did not really want to argue,
anyway. The point was to get you all informed about what is going on on
the Open MPI side, as this is not really transparent most of the time.
If the situation with MPICH2 is similar to that of Open MPI, I'll not
object to use MPICH2 as the default. We should support our users by
enabling them to run parallel applications out of the box, with the
tools that work best (for them).

> (3) encourage people to provide packages for both MPICH2 and OpenMPI
> (where possible, or only MPICH2 if OpenMPI not possible).

There currently is no easy way to do that easily, the burdon is on the
maintainers side. We can (and should!) encourage them, but we have to
accept that not everyone wants that. I'd personally would build only
against mpi-defaults-dev, for the reason that the user gets a working
application by installing the -mpi package, without the need to know
which of the (conflicting) MPI packages to choose[*]. On the other hand,
it would be a shame if users prefering MPICH2 would have to build all
packages by hand. But I do not see an easy technical solution to that so
we can ease the building of multiple MPI packages (semi-)automatically.
I'm happy for all ideas on that, though.

Best regards, and sorry for the long mail!
Manuel

[*] I'm aware of the fact that MPI users usually know about things like
that but since multi-core machines get more and more frequent, we need
to support the less clueful users at some point.

--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: MPI implementations in squeeze

2009-12-01T13:40:33Z

On Tue, Dec 01, 2009 at 11:31:02AM +0100, Manuel Prinz wrote:

> Am Montag, den 30.11.2009, 22:11 -0800 schrieb Nicholas Breen:
> > On Tue, Dec 01, 2009 at 03:49:20PM +1100, Drew Parsons wrote:
> > > From the point of view of a client package, what is now best practice
> > > for working with MPI? Is there a website/wiki/document explaining how
> > > to set up an MPI-using package, or is it just a matter of RTFM from
> > > mpi-default-dev?
> > >
> > > For context, gerris includes MPI support which is currently switched
> > > off. I would like to create an additional gerris-mpi package which has
> > > MPI switched on.
> >
> > No particular documentation that I'm aware of, though it's a good thought....
>
> I'm also not aware of that and really might be reasonable to write such
> a document. It seems to me that there has been no or not much
> cooperation of maintainers of MPI packages, which is changing at the
> moment and works out well. I'm really happy about that! So chances for
> MPI guidelines are good.
>
> But adding MPI support is usually as easy as Nicholas pointed out in his
> email. If one only wants to build an MPI version, build-depending on
> mpi-default-dev is best; if you want to build one package per MPI
> implementation, you have to do that yourself. Nicholas' gromacs package
> is a good example for that!
>

Nice to see things are going on. A policy document would be nice indeed,
with possibly use cases. Note that currently also hdf5 builds for
different MPI flavors with some specific hacks.

--
Francesco P. Lovergine

--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: MPI implementations in squeeze

2009-12-01T12:44:01Z

Le mardi 01 décembre 2009 à 21:20 +0100, Lucas Nussbaum a écrit :

> On 01/12/09 at 11:33 +0100, Manuel Prinz wrote:
> > Am Montag, den 09.11.2009, 16:47 -0800 schrieb Nicholas Breen:
> > > * should we start filing wishlist bugs asking packagers not to build against
> > > MPICH (1) and LAM?
> >
> > If noone objects by the end of the week, I will file the bugs then. The
> > number of affected packages is really low and the severity wishlist, so
> > I guess we do not need to go through the usual MBF hassle, or do we?
>
> So the plan would be to use OpenMPI on all architectures where it is
> supported, and MPICH2 on the other ones, using mpi-default?

To me, this would be the best solution.

We could do the third proposal (build for both MPICH2 & OpenMPI) but, at
least to me, it complexifies the build process to have to handle many
different MPI implementations for a low gain for the lambda user.

Sylvestre

--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: MPI implementations in squeeze

2009-12-01T12:20:22Z

On 01/12/09 at 11:33 +0100, Manuel Prinz wrote:
> Am Montag, den 09.11.2009, 16:47 -0800 schrieb Nicholas Breen:
> > * should we start filing wishlist bugs asking packagers not to build against
> > MPICH (1) and LAM?
>
> If noone objects by the end of the week, I will file the bugs then. The
> number of affected packages is really low and the severity wishlist, so
> I guess we do not need to go through the usual MBF hassle, or do we?

So the plan would be to use OpenMPI on all architectures where it is
supported, and MPICH2 on the other ones, using mpi-default?

What do we do with LAM and mpich1? Target their removal for squeeze?

While I would be fine with that, there are other possible plans:
(2) use MPICH2 as default everywhere (it is supported on all release
archs). Clearly, the package didn't receive a lot of testing yet,
but this is likely to be only a temporary problem.
(3) encourage people to provide packages for both MPICH2 and OpenMPI
(where possible, or only MPICH2 if OpenMPI not possible).
--
| Lucas Nussbaum
| lucas@... http://www.lucas-nussbaum.net/ |
| jabber: lucas@... GPG: 1024D/023B3F4F |

--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Bug#559006: ITP: mlpy -- high-performance Python package for predictive modeling

2009-12-01T09:40:48Z

On Tue, Dec 01, 2009 at 12:35:54AM -0500, Yaroslav Halchenko wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Yaroslav Halchenko <debian@...>
>
>
> * Package name : mlpy
> Version : 2.1.0
> Upstream Author : mlpy Developers - FBK-MPBA <albanese@...>
> * URL : https://mlpy.fbk.eu/
> * License : GPL-3+
> Programming Lang: C, Python
> Description : high-performance Python package for predictive modeling
> mlpy provides high level procedures that support, with few lines of
> code, the design of rich Data Analysis Protocols (DAPs) for
> preprocessing, clustering, predictive classification and feature
> selection. Methods are available for feature weighting and ranking,
> data resampling, error evaluation and experiment landscaping.
> .
> mlpy includes: SVM (Support Vector Machine), KNN (K Nearest
> Neighbor), FDA, SRDA, PDA, DLDA (Fisher, Spectral Regression,
> Penalized, Diagonal Linear Discriminant Analysis) for classification
> and feature weighting, I-RELIEF, DWT and FSSun for feature weighting,
> *RFE (Recursive Feature Elimination) and RFS (Recursive Forward
> Selection) for feature ranking, DWT, UWT, CWT (Discrete, Undecimated,
> Continuous Wavelet Transform), KNN imputing, DTW (Dynamic Time
> Warping), Hierarchical Clustering, k-medoids, Resampling Methods,
> Metric Functions, Canberra indicators.

This sounds like a nice target for Debian Science.

Yaroslav, do you consider group maintenance in this team?

Kind regards

Andreas.

--
http://fam-tille.de

--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: MPI implementations in squeeze

2009-12-01T02:33:52Z

Am Montag, den 09.11.2009, 16:47 -0800 schrieb Nicholas Breen:
> * should we start filing wishlist bugs asking packagers not to build against
> MPICH (1) and LAM?

If noone objects by the end of the week, I will file the bugs then. The
number of affected packages is really low and the severity wishlist, so
I guess we do not need to go through the usual MBF hassle, or do we?

Best regards
Manuel

--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: MPI implementations in squeeze

2009-12-01T02:31:02Z

Am Montag, den 30.11.2009, 22:11 -0800 schrieb Nicholas Breen:

> On Tue, Dec 01, 2009 at 03:49:20PM +1100, Drew Parsons wrote:
> > From the point of view of a client package, what is now best practice
> > for working with MPI? Is there a website/wiki/document explaining how
> > to set up an MPI-using package, or is it just a matter of RTFM from
> > mpi-default-dev?
> >
> > For context, gerris includes MPI support which is currently switched
> > off. I would like to create an additional gerris-mpi package which has
> > MPI switched on.
>
> No particular documentation that I'm aware of, though it's a good thought....

I'm also not aware of that and really might be reasonable to write such
a document. It seems to me that there has been no or not much
cooperation of maintainers of MPI packages, which is changing at the
moment and works out well. I'm really happy about that! So chances for
MPI guidelines are good.

But adding MPI support is usually as easy as Nicholas pointed out in his
email. If one only wants to build an MPI version, build-depending on
mpi-default-dev is best; if you want to build one package per MPI
implementation, you have to do that yourself. Nicholas' gromacs package
is a good example for that!

Best regards
Manuel

--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: MPI implementations in squeeze

2009-11-30T22:11:49Z

On Tue, Dec 01, 2009 at 03:49:20PM +1100, Drew Parsons wrote:
> I understand the final state of the modern Debian infrastructure for MPI
> is now in place (modulo the questions around deprecating MPICH and LAM).
> That is, the disruptive Open MPI transition is now complete, correct?

Yes, so far as I know. There might be the occasional need for a binNMU as
MPICH2 settles in and if mpi-default-dev switches to MPICH2 instead of LAM as
the backup, but those shouldn't interfere with testing migration.

> >From the point of view of a client package, what is now best practice
> for working with MPI? Is there a website/wiki/document explaining how
> to set up an MPI-using package, or is it just a matter of RTFM from
> mpi-default-dev?
>
> For context, gerris includes MPI support which is currently switched
> off. I would like to create an additional gerris-mpi package which has
> MPI switched on.

No particular documentation that I'm aware of, though it's a good thought....

If you just want one MPI package, it should be enough to Build-Depend on
mpi-default-dev and perform a build of your package with whatever flags are
necessary -- which ideally should be something simple like "configure
--enable-mpi CC=mpicc".

--
Nicholas Breen
nbreen@...

--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: MPI implementations in squeeze

2009-11-30T20:49:20Z

I understand the final state of the modern Debian infrastructure for MPI
is now in place (modulo the questions around deprecating MPICH and LAM).
That is, the disruptive Open MPI transition is now complete, correct?

>From the point of view of a client package, what is now best practice
for working with MPI? Is there a website/wiki/document explaining how
to set up an MPI-using package, or is it just a matter of RTFM from
mpi-default-dev?

For context, gerris includes MPI support which is currently switched
off. I would like to create an additional gerris-mpi package which has
MPI switched on.

Thanks,

Drew

On Mon, 2009-11-09 at 16:47 -0800, Nicholas Breen wrote:

> With the recent upload of MPICH2, we now have four separate MPI implementations
> in the archive: two with active upstreams and maintainers (MPICH2, OpenMPI) and
> two on terminal life support (MPICH, LAM).
>
> There's been some preliminary discussion before about dropping the latter two
> [1], though legacy support is an issue as well [2]. Currently, the MPI
> situation is fairly messy: 18 source packages depend on mpi-default-dev
> (OpenMPI or LAM, depending on architecture), but another 18 depend on various
> permutations of the implementations directly [3], with no particular
> consistency.
>
> >From a package maintainer standpoint, I'd like to see us start reducing the
> number of implementations to build client packages against, even if we maintain
> all the MPI implementations themselves (perhaps moving them to the 'oldlibs'
> section). What I'm wondering is:
>
> * in mpi-defaults, should MPICH2 replace LAM for architectures not supported
> by OpenMPI?
> * should we start filing wishlist bugs asking packagers not to build against
> MPICH (1) and LAM?
> * is it too late in the release cycle to propose this as a release goal?
> should squeeze+1 be the target instead? squeeze+2?
>
> This is orthogonal to solving #552429, which will need action before the
> squeeze release in any case.
>

--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: tasks overview wishlist: Canonical citing reference

2009-11-30T02:57:36Z

Le Mon, Oct 26, 2009 at 04:12:18PM +0100, Andreas Tille a écrit :

> On Mon, Oct 26, 2009 at 11:55:32PM +0900, Charles Plessy wrote:
> > Nevertheless, if there are good reasons to not store monolithic BibTeX
> > references and use another format or approach, I would be very interested to
> > hear them.
>
> Having BibTeX in the YAML format is probably OK. My question on QA was
> rather whether it iis a good idea to use the whole BibTeX record and
> simply store this as field value of a potential publication field. That
> does not really come handy if you want to do SQL queries about
> publications because your querying application would need a BibTeX parser.

Dear all,

I am starting to collect bibliographic information for the packages in the
Debian Med subversion repository as a background task (1 or 2 packages per
day). The references are broken up in a half-dozen of YAML mappings (think
hashes in Perl, or Field in Debian control files in the paragraph format). In
most cases the package contains one work that was published in one article, and
it is therefore easy to document “The” reference.

This of course break if there is more than one reference to take into account,
and it would also be more difficult to support on the other side: in
particular, the Blends web sentinels (‘tasks files’) are designed to show one
reference only.

Given that packages that would need more than one reference are anyway the
exception to the rule, I am considering to overcome the difficulty by simply
not supporting it, or providing a link to an upstream page listing the
references if available.

What is your opinion on this?

Have a nice day,

--
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Future Icon Records] You've been added to our mailing list.

2009-11-28T19:59:03Z

Hi I represent KONVICT MUSIC recording artist COLBY O'DONIS (Just Dance Ft Colby O'Donis. Beautiful Ft Colby O'Donis) and we want to share with you His first Original Christmas song I made a radio edit of so happy here it is if you like it Radio Edit Of - So Happy https://rcpt.yousendit.com/782608652/9a8972b464bfc006aa5139a89722060d Instrumental Radio Edit - So Happy https://rcpt.yousendit.com/782608822/4c2efde9129f9900fe9782387ef48410 

--------
Get your free download from Future Icon Records here: http://fburls.com/47-u4AlvIZr
--------

You have been added to the Future Icon Records fan list!

If you would like to verify your info or add more to your fan profile, you can do so by clicking on the following link:

http://www.FanBridge.com/signup/fansignup.php?userid=129853&email=debian-science@...&confCode=24eBXPbbe2a1FXPFB64tahttdK

--
This list is powered by FanBridge, the world's leading provider of fan relationship management services for artists.

With FanBridge your information is always secure.

For more information about FanBridge please visit http://www.FanBridge.com/learn/
--

***Important: Please be sure to add the email address (futureiconrecords@...) to your safe senders list.***

Here's how:

Gmail
1. Click Contacts along the left side of any Gmail page.
2. Click Add Contact.
3. In the primary email address box, type futureiconrecords@....
4. Click Save.

AOL (version 9.0 or higher)
1. Click the Mail menu and select Address Book.
2. In the pop up box, click the Add button.
3. In the "Other E-Mail" field, type futureiconrecords@....
4. Make our From address the "Primary E-Mail" address by checking the associated check box.
5. Click the Save button.

AOL 8.0
1. Open this confirmation email.
2. Click Add Address.
3. Verify the sender's contact information (futureiconrecords@...).
4. Click Save.

Yahoo!
1. Click the "addresses" button
2. Select "Add Contact"
3. Save the futureiconrecords@... to your contacts list.

Hotmail
1. Click Options.
2. On the left side of the page, click Mail, and then click Junk E-Mail Protection.
3. Click Safe List.
4. Type futureiconrecords@..., and then click Add.

Outlook
1. Right-click on a message from futureiconrecords@....
2. Point to Junk E-mail, and click Add Sender to Safe Senders List.

----------------------------------------
Future Icon Records sent this email to debian-science@...
Questions? Contact futureiconrecords@... or Future Icon Records, c/o FanBridge, Inc. - 14525 SW Millikan Way, #16910, Beaverton, Oregon 97005, United States

Update Your Information - http://fburls.com/32-dc4PRCfT
Forward to a friend - http://fburls.com/17-7pJmLa0X
Unsubscribe - http://fburls.com/56-6twb833R
Privacy Policy - http://www.FanBridge.com/learn/privacy.php

This email message is powered by FanBridge:
http://www.FanBridge.com/b.php?id=129853
Powering Valuable Fan Relationships

--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: RFS: lrslib, package to enumerate solutions to linear inequalities

2009-11-26T13:15:33Z

Hi David,

On Thu, Nov 26, 2009 at 04:39:20PM -0400, David Bremner wrote:

> I am looking for a sponsor for my package "lrslib".
>
> * Package name : lrslib
> Version : 0.42c-1
> Upstream Author : David Avis <avis@...>
> * URL : http://cgm.cs.mcgill.ca
> * License : GPL2+
> Language: : C
> Section : math
>
> It builds these binary packages:
> liblrs-dev - package to enumerate vertices and extreme rays (static libraries)
> liblrs0d - package to enumerate vertices and extreme rays (shared libraries)
> lrslib - package to enumerate vertices and extreme rays of a convex polyhedron
>
> The package appears to be lintian (-I) clean. I even fixed the
> spelling-mistake-in-binary warning after some grumbling :).
>
> The upload would fix these bugs: 454469

Looks good. Uploaded.

> My motivation for maintaining this package is that is a Build
> dependency for polymake (ITP #461976), and also useful as a tool for
> mathematicians and other scientists and engineers.

If you want me to sponsor polymake some day, just CC me again. I'm glad
if I can help!

Hauke

PS: I'm offline now until at least tuesday, but NEW handling will need
some time anways, right? :)

signature.asc (229 bytes) Download Attachment

RFS: lrslib, package to enumerate solutions to linear inequalities

2009-11-26T12:39:20Z

rom: David Bremner <bremner@...>
To: debian-mentors@...
Subject: RFS: lrslib

Dear All;

I am looking for a sponsor for my package "lrslib".

* Package name : lrslib
Version : 0.42c-1
Upstream Author : David Avis <avis@...>
* URL : http://cgm.cs.mcgill.ca
* License : GPL2+
Language: : C
Section : math

It builds these binary packages:
liblrs-dev - package to enumerate vertices and extreme rays (static libraries)
liblrs0d - package to enumerate vertices and extreme rays (shared libraries)
lrslib - package to enumerate vertices and extreme rays of a convex polyhedron

The package appears to be lintian (-I) clean. I even fixed the
spelling-mistake-in-binary warning after some grumbling :).

The upload would fix these bugs: 454469

My motivation for maintaining this package is that is a Build
dependency for polymake (ITP #461976), and also useful as a tool for
mathematicians and other scientists and engineers.

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/l/lrslib
- Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free
- dget http://mentors.debian.net/debian/pool/main/l/lrslib/lrslib_0.42c-1.dsc

You can check the package out from git

git clone git://git.debian.org/debian-science/packages/lrslib

There is a gpg signed tag debian/0.42c-1rc2. the original source
tarball is stored using pristine tar in the same repo.

I would be glad if someone uploaded this package for me.

Kind regards
David Bremner

--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Auto Backporting (Was: Backports of scientific packages)

2009-11-24T02:10:19Z

Hi Francesco!

Am Dienstag, den 24.11.2009, 09:04 +0100 schrieb Francesco Pietra:
> As the initial trigger of these interventions, may I ask if anything
> has been done to provide version 4.0 of GROMACS for amd64 lenny?

Not as far as I know. If it's just for this package, I can send you the
backported version I use. If it's for the Debian Science backports, this
does not exist (yet), AFAIK. I will soon have better infrastructure
though, so I might be able to set that up. But this might be mid of
December (or later) until that's available.

In case anyone would like to help, I can give access to the machine.

Best regards
Manuel

--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Auto Backporting (Was: Backports of scientific packages)

2009-11-24T00:04:50Z

Hello:
As the initial trigger of these interventions, may I ask if anything
has been done to provide version 4.0 of GROMACS for amd64 lenny?
thanks
francesco pietra

On Fri, Sep 25, 2009 at 2:56 PM, Andreas Tille <andreas@...> wrote:

> [Reply-To set to debian-devel because this topic belongs here.]
>
> On Fri, Sep 25, 2009 at 12:58:00PM +0200, Manuel Prinz wrote:
>>
>> Yes. I like the idea but we simply can't rebuild everything from the
>> task pages of these blends since there are also tools from KDE or GNOME
>> which would mean to backport quite a lot of unrelated stuff. Also,
>> packages with code in interpreted language can almost always be used
>> directly from testing. But I think auto-building could work for a
>> well-defined subset of packages.
>
> IMHO this problem is not really Debian Science or Blends related and the
> idea to handle backports analog to non-free autobuilds sounds quite
> reasonable - but in this case we *really* make it analog tp non-free which
> works with a debian/control field
>
> XS-Autobuild: yes
>
> So why not using a similar field
>
> XS-Autobackport: yes
>
> ? Well, it's definitely not that easy but I see a quite large set of
> packages (specifically in the Debian Science field) which perfectly
> compiles against Build-Depends of stable. If we could handle this set
> automatically for a first shot and think later about those packages
> which need Build-Depends which are not available in stable this would
> be an interesting thing.
>
> So in short: we should choose the "well-defined" subset of packages
> which are candidates for autobackporting according to their feature to
> be buildable inside stable and using an control field to mark the
> packages that way.
>
> Kind regards
>
> Andreas.
>
> --
> http://fam-tille.de
> Klarmachen zum Ändern!
>
>
> --
> To UNSUBSCRIBE, email to debian-science-request@...
> with a subject of "unsubscribe". Trouble? Contact listmaster@...
>
>

--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Is anyone interested in packaging VisIt?

2009-11-22T15:48:44Z

Am Montag, den 23.11.2009, 00:10 +0100 schrieb Francesco Poli:
> is there anyone willing to package VisIt for Debian?
>
> My RFP (see bug #395573) was converted into an ITP, but later was
> converted back into an RFP...

I did not know about that but started packaging it a while ago. The
files are surely around somewhere for those interested.

I remember having a lot of trouble with it for several reasons. IIRC it
was some weird build system and included libraries to get rid of. I will
not have any time to have a second look at it before next month, I
guess, but could dig for the files if there's interest. They probably do
not build anything working, I guess.

Even if I give it a second try to package, some co-maintainer would
certainly be welcome; even better, someone who would take over
maintainership.

> Please Cc: me *and* the bug on replies, thanks.

Done.

Best regards
Manuel

--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...