[Neurodebian-upstream] Debian package for mpi4py

[Yury V. Zaytsev]

Hi!

On Fri, 2010-12-03 at 11:28 -0500, Yaroslav Halchenko wrote:

> if you want to help with packaging and co-maintain, or even take over
> so we then only mentor/sponsor your uploads into Debian and
> provide backports (if any) from neuro.debian.bet -- you are welcome to
> do so!

I'm not a DD / DM (yet?). I've just recently got enough DD signatures on
my key, but this whole application thing kind of scares me off, so for
now I'll have to ping you every once in a while to upload.

> We have filed an ITP but haven't looked at packaging it yet besides
> creating a "proper" GIT clone of the SVN... I could push it if you
> like so you could use it too to track SVN repository from GIT.

If you can create the basic layout for me and push it to your host, this
would be fine with me. Do you need my key?

> Well, if you jump-in, whatever fits you best would work for us.
> Only that we would really prefer use of GIT for packaging, but it is
> also not too critical since we could interact with out via git svn.

Nah, I prefer git, but I'm not the admin at Alioth and I don't have a
clue how to properly convert my package to git (maybe even starting anew
would be the right thing to do...). 

In fact I don't use svn-buildpackage, I just update the package
pdbuilding in the meantime and when it works for me, I commit the diff
to the svn.

> For GIT packaging I am using git-buildpackage which makes things
> easier I think.  For the basic intro, enjoy Guido's talk at debconf10
> http://penta.debconf.org/dc10_schedule/events/634.en.html or just
> glimpse through the documentation
> http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.html
> or little howtos like http://workaround.org/debian-git-comaintenance

That's nice, I was actually looking for this kind of tutorials. I will
watch the talk tomorrow on the train and hopefully it will help me to
get started with your system.

> Basing on upstream VCS is done for easier interactions between packaging
> and upstream -- so we could easily build from any snapshot of upstream
> repository (e.g. when upstream informs us that release is coming sooon);
> or cherry-pick/commit necessary fixes directly upstream (if they grant
> us permission) while upstream is getting ready to kick out a new
> release.  Also with such setup 'debcheckout' provides user with a
> complete repository not only for packaging but also for upstream, so
> people could get involved and contribute with ease.

Hmmm... in the case of mpi4py they have public read-only svn repo at
Google code [1], so I guess your second approach could work. 

I've got few trivial patches through just by sending them to the mailing
list, so upstream interaction is not much of a problem (git format-patch
and go). The software is maintained, the author is available and quite
responsive to the inquiries.

[1]: http://code.google.com/p/mpi4py/source/checkout

> > (2) don't want to re-invent the wheel if you already have something to
> > start with, I'd rather take this and update it to the usable condition
> 
> smart decision ;)  So, just decide how do you want to proceed (just take
> over or co-maintain)... 

If you create the basic layout for me we can see if I can find time to
package it. I already have a template package that I created for NEST,
so it might actually work out...
 
-- 
Sincerely yours,
Yury V. Zaytsev