Bug#732360: Please privide pristine-tar branch

Andreas Tille andreas at an3as.eu
Mon Mar 17 12:14:52 UTC 2014


Hi Ghislain,

On Sun, Mar 16, 2014 at 09:11:12PM +0000, Ghislain Vaillant wrote:
> On Sun, 2014-03-16 at 21:04 +0100, Andreas Tille wrote:
> > I would like to sponsor ismrmrd but there are some issues with the
> > packaging.
> > 
> Thank you for stepping-up again to mentor one of my packages.

Sure, that's fine.  I was aware of some "rush" of sponsees when I
started SoB. :-)
 
> >   1. The pristine-tar branch is missing.  Please use
> >          git import-orig --pristine-tar <origtarball>
> >      as it is explained in the team policy
> > 
> The source distribution is a zip file that certainly needs a repack to a
> suitable tarball format. I have been doing it manually so far. 

Well, but finally you *have* created some orig.tar.gz which is the basis
of your packaging.  Specifically if you can not use the download from
upstream you should inject this into Git to make sure we will use the
very same tarball.
 
> >   2. Please set the Science team mailing list as Maintainer and
> >      yourself as Uploader (as explained in team policy)
> > 
> Done

OK.
 
> >   3. If you have good reasons to stick to debhelper compat
> >      level 8 please mention them in debian/README.source
> >      otherwise please use level 9
> Reason is that I tested the package on Ubuntu LTS before (personal PPA),
> where setting debhelper to v9 was not possible.
> 
> 
> The ultimate goal is to have the package accepted in Debian, but
> upstream would also like to support the current Ubuntu LTS. I wanted to
> avoid duplicating my packaging effort, hence some of the choices above.
> If you can suggest better pieces of advice regarding this issue, I'd be
> keen on hearing from them. 

Well, this is somehow a reason.  I was not aware that Ubuntu LTS is
lagging behind that much.  I do not want to spoil your final target but
in this case you should make sure manually that the test suite will be
run in the build process.  In my eyes this is the most important feature
of debhelper compat 9 and I do not really care about the version number
but the functionality of running a test if it is available.  So I would
like you to

  1. Put the paragraph above as explanation for using debhelper 8 in
     debian/README.source (just to make sure that we will not forget
     and also put the exact LTS version in since the next LTS version
     will surely have debhelper 9)

  2. Make sure the test suite will be run successfully in the build
     process.
 
BTW, when speaking about the test suite:  An autopkgtest control file
would be also a very welcome feature.  I think if we are talking about
science we should test our packages as best as possible.

Kind regards

       Andreas.

-- 
http://fam-tille.de



More information about the debian-science-maintainers mailing list