[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[MoM] Re: bart - tools for computational magnetic resonance imaging

Hi Andreas and Ghislain,

the bart package now produces a -dev package and a
octave-bart package. It also includes a bash completion
script. pristine-tar produces the correct upstream
tar ball.

I would appreciate if you could take a look and let
me know what else could be improved...

Also I wonder whether there is a way to build and
test the package on other architectures than amd64?

Season's greetings,

Ghislain Vaillant:
> On 07/12/15 08:18, Uecker, Martin wrote:
> >
> > Hi Andreas,
> >
> >> On Sun, Dec 06, 2015 at 11:59:02PM +0000, Uecker, Martin wrote:
> >>>> Put simply, pristine-tar is our way to encapsulate access to the source
> >>>> tarball used for packaging. Someone who checks out a d-science
> >>>> repository does not need to know where the tarball comes from (github,
> >>>> bitbucket, PyPI...), he or she can just check it out using pristine-tar
> >>>> on the packaging repository.
> >>>
> >>> Ok, I created a tar ball using a git archive (which matches what
> >>> github does) and then used pristine-tar to check it in.
> >>
> >> I think this is a misunderstanding.  You should write a debian/watch file
> >> (line 22 of this template
> >>    https://anonscm.debian.org/viewvc/debian-med/trunk/package_template/watch?revision=20511&view=markup
> >> is your friend) and use the downloaded tarball when importing pristine-tar.
> >
> > Ok, done.
> >
> > Please note that there is no difference between downloading
> > tar balls from github which uses 'git archive' to create them
> > or creating them locally using 'git archive' (with the
> > right arguments). This already produces bit-identical results
> > (with the same hash)! So there is really no point in downloading
> > upstream tarballs from Github when one has a local copy of the git
> > repository.
> Actually, you can do it with `gbp buildpackage` by passing the 
> --git-no-pristine-tar and --git-pristine-tar-commit, which effectively 
> will produce the pristine tarball from the tag you based your packaging off.
> Andreas gave you the general guideline which works for any source. The 
> --git*pristine-tar* options only work if you are using the upstream git 
> repository.
> FYI, make sure you have a valid watch file (although you are not using 
> uscan), because that is also what is used by the Debian Package Tracking 
> System to signal when new upstream releases are available.
> >> You could add these in additional python-bart octave-bart binary
> >> packages (sorry, matlab can not be provided as official Debian package).
> >> You should read the according pages at wiki.debian.org where to put
> >> Python modules (or you just check your local system where these are
> >> stored) and Octave files (I never dealt with these but I guess there is
> >> a wiki paga as well).  Feel free to ask me if you are struck in the
> >> jungle of documentation and I'll provide more specific pointers.
> >
> > Ok, I have to look at it. There are only very few small scripts,
> > so I would rather put it in the same package.
> >
> >> Another remark to the packaging:  Currently there is a libgsl migration
> >> ongoing and you should use libgsl-dev instead of libgsl0-dev.
> >
> > Done. Although now it doesn't build locally on my Ubuntu machine
> > anymore (only using pbuilder in a sid change root).
> You could use something like libgsl0-dev | libgsl-dev to stay compatible 
> with earlier versions?
> Ghis

Reply to: