Re: Packaging gwamar for Debian
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
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
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
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
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