Re: Packaging gwamar for Debian

2015-12-06 Thread Michał Woźniak 
Hi Andreas,
I have resolved all the issues listed in your mail. Still, if possible I
would prefer to have a week more time to clean up console messages to be
more clear and less confusing.

Please find my answers to your comments one by one:

 0. fixed, I attach version number to each zip file when building (the
current version is 1.15.1)

  1. I have attached Apache License 2 in LICENSE file.

  2. Indeed I've searched "print " and found some results which  resolved.
I've tested it on Python3.

  3. indeed, this was ugly, I've moved all external tools configuration to
a separate config_tools.txt, and change accordingly to your proposal

  4. I've improved the information on what happens when no parameters are
provided to the program. The error you were getting was caused because the
default action "-a" parameter to set to a method which assumed some
preprocessing. Now, I require the parameter to be explicitly set in console.

Best regards,
Michal

2015-11-21 18:53 GMT+01:00 Andreas Tille :

> Hello,
>
> I'm writing you on behalf of the Debian Med team that has the objective
> to package all free software that is relevant in Biology and Medicine
> for official Debian.
>
> I came across GWAMAR[1] and started the packaging in Debian Git[2].
> When doing so I stumbled upons some issues in the download archive[3]:
>
>   0. Just a comment:  It would be more convenient to find versioned
>  download archives rather than versioned directories.  The
>  rationale behind this is that you have files with the same name
>  but different content.
>
>   1. I did not found any explicite license statement neither at the
>  website nor inside the code.  Could you be so kind to clarify
>  this?
>
>   2. At Bitbucket[4] you write:
>This software is written in Python, thus Python 2 or 3 is
>required to run GWAMAR.
>  When trying to build with Python3 I've git some errors
>  (basically in print statements with Python2 syntax.  Please
>  let me know if you are interested in patches fixing this.
>
>   3. I noticed that the default config file in the download archive
>  contains several private PATH settings.  I patched these to
>  the Debian locations in the packaging git[5].  It would be
>  great if you could change the default config file to a more
>  neutral setting.
>
>   4. Finally I endet up by an error message
>
>File "a1_save_details_scores_all.py", line 161, in 
>  input_fh = open(input_fn)
>IOError: [Errno 2] No such file or directory:
> 'datasets/mtu173/exP//res_profiles.txt'
>
>  I have no idea how to deal with this since this file is
>  neither in the download tarball nor can I see it in the
>  repository at Bitbucket.
>
> I hope you like the intend to package GWAMAR for Debian and can
> help with these issues.
>
> Kind regards
>
>   Andreas.
>
> [1] http://bioputer.mimuw.edu.pl/gwamar/
> [2] git://anonscm.debian.org/debian-med/gwamar.git
> [3] http://bioputer.mimuw.edu.pl/gwamar/software/gwamar_v1.14/gwamar.zip
> [4] https://bitbucket.org/mimowo/gwamar
> [5]
> https://anonscm.debian.org/cgit/debian-med/gwamar.git/tree/debian/patches/adapt_debian_locations_of_binaries.patch
>
> --
> http://fam-tille.de
>

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

2015-12-06 Thread Ghislain Vaillant 



On 06/12/15 12:32, Uecker, Martin wrote:

Hi Andreas,


Ok, I put it in /git/debian-med/bart.git as described in the
debian-med policy.

I checked this out and added Vcs fields and Homepage to Debian control
(please pull).  I noticed that the pristine-tar branch is missing in the
git repository.  You can get this easily by redoing

 gbp import-orig --pristine-tar your_orig_tar_gz

(just make sure you use the --pristine-tar option) and push the
pristine-tar branch.  The rationale is that we can both easily work
on a byte identical tarball right from the Git archive.

Ok, what is the deal with pristine-tar? Our upstream tar balls are
generated by github using git-archive. So there does not seem to
be any point to create tar balls just to re-import them using
pristine-tar, or is there?


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.



I assume that the debian/control file is missing other Build-Depends
than just debhelper.

Yep. I added some. It builds using git-pbuilder.


FYI, it should also be possible to build your source package without 
gbp, by checking out the source tarball with pristine-tar and calling 
dpkg-buildpackage on master.


It is also a good way to test whether your clean target works as 
intended, by running dpkg-buildpackage twice and see whether it 
succeeds. If the clean target is insufficient, dpkg-buildpackage will 
complain of a mismatch between the source tarball and the content of the 
packaging tree.



I'd also recommend to use

 cme fix dpkg-control

which would bump your Standards-Version to 3.9.6 (which you can also do
manually but cme is a nifty tool I'd like to introduce to newcomers).

My experience so far: It pulls in a million of perl packages, then I had to
figure out that I still have to install an extra package for dpkg-control
to work, then it complains that it doesn't know libpng-dev, but if I replace
it with libpng12-dev fixes it to be libpng-dev again. It also spits out a
lot of incomprehensible warnings about the VCS-* lines. It didn't bump
the standards version, but decides to do some arbitrary reformatting ;-)


Yes cme can be a bit picky sometimes.

Anyway, Standards-Version should be set to 3.9.6 indeed, which Lintian 
would complain about later when you build the package.


Running licensecheck on the source tree revealed a few files which have 
missing copyright headers:


 licensecheck -r --copyright . | grep "No copyright"
./vars.m: *No copyright* UNKNOWN
./update-version.sh: *No copyright* UNKNOWN
./makedoc.sh: *No copyright* UNKNOWN
./src/simu/phantom.h: *No copyright* UNKNOWN
./src/simu/sens.h: *No copyright* UNKNOWN
./src/mat2cfl.c: *No copyright* UNKNOWN
./src/wavelet3/wl3-cuda.h: *No copyright* UNKNOWN
./src/wavelet3/wavthresh.h: *No copyright* UNKNOWN
./src/linops/sum.h: *No copyright* UNKNOWN
./src/linops/ufft.h: *No copyright* UNKNOWN
./src/linops/sampling.h: *No copyright* UNKNOWN
./src/linops/rvc.h: *No copyright* UNKNOWN
./src/dfwavelet/prox_dfwavelet.h: *No copyright* UNKNOWN
./src/sake/sake.h: *No copyright* UNKNOWN
./src/calib/calmat.h: *No copyright* UNKNOWN
./src/calib/cc.h: *No copyright* UNKNOWN
./src/num/simplex.h: *No copyright* UNKNOWN
./src/num/convoaa.h: *No copyright* UNKNOWN
./src/num/shuffle.h: *No copyright* UNKNOWN
./src/num/shuffle.c: *No copyright* UNKNOWN
./src/num/filter.h: *No copyright* UNKNOWN
./src/iter/vec.h: *No copyright* UNKNOWN
./src/iter/vec.c: *No copyright* UNKNOWN
./src/ismrm/read.h: *No copyright* UNKNOWN
./src/misc/version.h: *No copyright* UNKNOWN
./src/misc/cppwrap.h: *No copyright* UNKNOWN
./src/misc/pcaa.h: *No copyright* UNKNOWN
./src/misc/version.c: *No copyright* UNKNOWN
./src/misc/utils.h: *No copyright* UNKNOWN
./src/misc/cppmap.h: *No copyright* UNKNOWN
./src/misc/png.h: *No copyright* UNKNOWN
./src/misc/dicom.h: *No copyright* UNKNOWN
./src/bbox.c: *No copyright* UNKNOWN
./ar_lock.sh: *No copyright* UNKNOWN
./update-if-changed.sh: *No copyright* UNKNOWN
./git-version.sh: *No copyright* UNKNOWN
./matlab/bart.m: *No copyright* UNKNOWN
./matlab/writecfl.m: *No copyright* UNKNOWN
./matlab/readcfl.m: *No copyright* UNKNOWN
./scripts/rtnlinv.m: *No copyright* UNKNOWN
./vars.sh: *No copyright* UNKNOWN
./octview.m: *No copyright* UNKNOWN

Which you may or may not want to act upon. Since the other source files 
have one it might be picked up during the review process anyway.


Otherwise, looks good.

Quick question, is the package supposed to install just the bart 
executable and its accompanying documentation or something else in 
addition ?


Cheers,
Ghis

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

2015-12-06 Thread Uecker, Martin 

Hi Andreas,

> > 
> > Ok, I put it in /git/debian-med/bart.git as described in the
> > debian-med policy.
> 
> I checked this out and added Vcs fields and Homepage to Debian control
> (please pull).  I noticed that the pristine-tar branch is missing in the
> git repository.  You can get this easily by redoing
> 
> gbp import-orig --pristine-tar your_orig_tar_gz
> 
> (just make sure you use the --pristine-tar option) and push the
> pristine-tar branch.  The rationale is that we can both easily work
> on a byte identical tarball right from the Git archive.

Ok, what is the deal with pristine-tar? Our upstream tar balls are
generated by github using git-archive. So there does not seem to
be any point to create tar balls just to re-import them using 
pristine-tar, or is there?

> I assume that the debian/control file is missing other Build-Depends
> than just debhelper.  

Yep. I added some. It builds using git-pbuilder.

> I'd also recommend to use
> 
> cme fix dpkg-control
> 
> which would bump your Standards-Version to 3.9.6 (which you can also do
> manually but cme is a nifty tool I'd like to introduce to newcomers).

My experience so far: It pulls in a million of perl packages, then I had to 
figure out that I still have to install an extra package for dpkg-control 
to work, then it complains that it doesn't know libpng-dev, but if I replace
it with libpng12-dev fixes it to be libpng-dev again. It also spits out a 
lot of incomprehensible warnings about the VCS-* lines. It didn't bump
the standards version, but decides to do some arbitrary reformatting ;-)

Martin

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

2015-12-06 Thread Uecker, Martin 
Am Sonntag, den 06.12.2015, 13:57 + schrieb Ghislain Vaillant:
> 
> On 06/12/15 12:32, Uecker, Martin wrote:
> > Hi Andreas,
> >
> >>> Ok, I put it in /git/debian-med/bart.git as described in the
> >>> debian-med policy.
> >> I checked this out and added Vcs fields and Homepage to Debian control
> >> (please pull).  I noticed that the pristine-tar branch is missing in the
> >> git repository.  You can get this easily by redoing
> >>
> >>  gbp import-orig --pristine-tar your_orig_tar_gz
> >>
> >> (just make sure you use the --pristine-tar option) and push the
> >> pristine-tar branch.  The rationale is that we can both easily work
> >> on a byte identical tarball right from the Git archive.
> > Ok, what is the deal with pristine-tar? Our upstream tar balls are
> > generated by github using git-archive. So there does not seem to
> > be any point to create tar balls just to re-import them using
> > pristine-tar, or is there?
> 
> 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.

gbp can also create tar balls from the same tag and check
in ione step, but somehow the hash does not seem to match
exactly (the content does). I wonder why...


...
> Running licensecheck on the source tree revealed a few files which have 
> missing copyright headers:

...
> Which you may or may not want to act upon. Since the other source files 
> have one it might be picked up during the review process anyway.

I don't see a reason to change this if it isn't necessary. 

> Otherwise, looks good.
> 
> Quick question, is the package supposed to install just the bart 
> executable and its accompanying documentation or something else in 
> addition ?

I also want to add octave/matlab/python scripts. But I am not
sure where to put them. I would be nice if there was a way to
add them to the default search path for octave/matlab, for
example.

Martin

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

2015-12-06 Thread andr...@an3as.eu 
Hi Martin,

On Sun, Dec 06, 2015 at 11:59:02PM +, 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=markup
is your friend) and use the downloaded tarball when importing pristine-tar.
 
> gbp can also create tar balls from the same tag and check
> in ione step, but somehow the hash does not seem to match
> exactly (the content does). I wonder why...

You stumbled upon the very problem pristine-tar is solving:  Tarballs
simply have different checksums even if featuring identical content.
This is for instance due to different time stamps, user ids etc after
unpackaging on a target system.  Feel free to seek Debian lists for
several discussions explaining the problem.

> > Quick question, is the package supposed to install just the bart 
> > executable and its accompanying documentation or something else in 
> > addition ?
> 
> I also want to add octave/matlab/python scripts. But I am not
> sure where to put them. I would be nice if there was a way to
> add them to the default search path for octave/matlab, for
> example.

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.
 
Another remark to the packaging:  Currently there is a libgsl migration
ongoing and you should use libgsl-dev instead of libgsl0-dev.

Kind regards

   Andreas.

-- 
http://fam-tille.de