Re: [MoM] Re: bart - tools for computational magnetic resonance imaging
On 07/12/15 08:18, Uecker, Martin wrote:
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
is your friend) and use the downloaded tarball when importing pristine-tar.
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
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
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?