Re: Packaging of software used at EMBL Grenoble
Hi Mickaël,
thanks for your introduction - it is quite important for us to have a
contact point at EMBL and I'm quite positive to establish a fruitful
cooperation to possibly have all your needs packaged for Wheezy+1.
On Fri, Jun 29, 2012 at 02:21:08PM +0200, Mickaël Canévet wrote:
> ...
> some electron microscopy softs that our users are using.
If you look at the tasks of our web sentinel[1] do you think that the
software you are mentioning below could deserve a new category / task
for instance med-emicro (or some better name)? It might be that the
rather filled med-bio would otherwise need to carry even more packages
of a quite disjunct working field. Users who need both could install
two metapackages easily and it is also perfectly possible to have a
single package in more than one task (which are not perfectly exclusive
categories but rather guided by the idea what might a user of this field
expect inside a task).
> Currently they use this list of software:
>
> - AMoRe (http://mem.ibs.fr/JORGE/index.html )
> - atsas (EMBL Hamburg, not sure we can re-distribute it)
> - blast (not sure if it's a former version of the package blast2 that
> already exists in debian)
This should be checked. If you really might need a previous of the
currently available version it might be worth checking whether
snapshot.debian.org there is some packaging stuff for the old version.
But this could be discussed here.
> - bsoft (http://lsbr.niams.nih.gov/bsoft/ )
> - chimera (http://www.cgl.ucsf.edu/chimera/ )
> - coot (http://lmb.bioch.ox.ac.uk/coot/ )
> - ctfind3 and ctftilt (http://emlab.rose2.brandeis.edu/ctf ) (GPLv3)
> - eman2 (http://blake.bcm.edu/emanwiki/ )
> - embfactor (https://sites.google.com/site/3demimageprocessing/embfactor
> )
> - empft/em3dr
> (http://bilbo.bio.purdue.edu/~viruswww/Rossmann_home/softwares/river_programs/para-pft-em3dr.php )
> - flex-em (http://salilab.org/Flex-EM/ )
> - frealign (http://emlab.rose2.brandeis.edu/frealign ) (GPLv3)
> - image2000 (http://www2.mrc-lmb.cam.ac.uk/image2000.html )
> - imagic (http://www.imagescience.de/imagic.html )
> - imod (http://bio3d.colorado.edu/imod/ )
> - maloc (http://fetk.org/codes/maloc/ )
> - modeller (http://salilab.org/modeller/ )
> - naccess (http://www.bioinf.manchester.ac.uk/naccess/ )
> - nuccyl (http://www.biosci.ki.se/groups/ljo/software/nuccyl.html )
> - peet (http://bio3d.colorado.edu/PEET/ )
> - relion (http://www2.mrc-lmb.cam.ac.uk/relion/index.php/Main_Page )
> - Rico (http://mem.ibs.fr/JORGE/index.html )
> - saxsview (http://saxsview.sourceforge.net/ )
> - spider (http://www.wadsworth.org/spider_doc/spider/docs/spider.html )
> - tiltpicker (http://www.ncbi.nlm.nih.gov/pubmed/19374019 )
> - uro (http://mem.ibs.fr/JORGE/index.html )
> - veda (http://mem.ibs.fr/GAEL/ )
> - vmd (http://www.ks.uiuc.edu/Research/vmd/ )
> - xmipp (http://xmipp.cnb.csic.es/twiki/bin/view/Xmipp/WebHome )
> - zdock (http://zlab.umassmed.edu/zdock/ )
>
> Most used at EMBL Grenoble are spider, xmipp and eman2.
So it sounds reasonable to start here. I would suggest you should in
advance decide whether you want to maintain the whole group of packages
in SVN or Git - both is possible in the team and the rules are
(hopefully) well documented in our group policy document[2] (which
I'd strongly recommend to anybody who wants to join the team.)
> I already packaged Xmipp 3.0 on wheezy, but I can't compile it on
> squeeze as it needs python-numpy >= 1.6 which is not available even in
> squeeze-backports .
Cool. We would be happy to see showing this up in our VCS (whatever you
decide - see above) and make it an official package. For the moment I
can not comment on the backporting issue - I have not yet dealt with
this in the past but it does depend on how urgently you need this to
decide whether we should spend some time into this.
> I also made a package for spider, but it's not very clean yet... I
> worked with the developer to make it compile with gfortran and not only
> with PGI or ifort.
We could easily have a look into this. There is also some offer for
mentoring to enhance pakaging skills which is called "Mentoring of
Month"[3] - I'd be happe to provide this remote training and I hope
this could extend the lack of time for the Debian training workshop
at ESFR.
> My co-worker is currently working on ctfind and ctftilt.
>
> The main problem we encountered so far is that that kind of program
> often lack of clean Makefile and have non traditional install procedure
> (./configure && make && make install), so we have to write it first...
Yep - that is a problem we do frequently observe. The best way to cope
with this is to provide these as patches to upstream to hopefully
simplify packaging for the future (and also when doing so helping other
non-Debian user - we just give back something and thus strengthen the
contact to upstream).
> We may not have a lot of time to dedicate to packaging in the next few
> weeks, but we'll try to get a few software in Debian Med before the end
> of the year.
It's perfectly normal that volunteer time is limited and setting the
goal for end of year is very reasonable and I'm pretty sure that we will
not be able to work down your full list - but picking the most important
25% would be a very good start and we will really love to support this.
> I'd like to know how we can start working with Debian Med (include list
> of software on this page:
> http://debian-med.alioth.debian.org/tasks/bio , upload unofficial
> packages for review, become a member of the debian med team...) and if
> some of you is using one of the softs we use.
The first step should be reading the policy document[2] which answers
hopefully all of these questions. The first step is to become a member
of the Debian Med team on Alioth and make sure you can ssh to
alioth.debian.org (as it is described in the SSH tips). Than you can
commit to your VCS of choice and ping this list that some new software
is ready for inspection - than we will start action. This method has
proven to be quite effective in the past and I'd love to help you and
your colleagues taking some possible initial hurdles.
Kind regards and thanks for your interest in Debian Med
Andreas.
[1] http://debian-med.alioth.debian.org/tasks/
[2] http://debian-med.alioth.debian.org/docs/policy.html
[3] http://wiki.debian.org/DebianMed/MoM
--
http://fam-tille.de
Reply to: