Hello Andreas, Thank you for instructions for using dch, I hope now I got it right.
1) I edited patch use_debian_packaged_seqtk.patch so I guess the problem with seqtk should be resolved now. 2) I have this error on Ubuntu xenial, Debian jessie and after you mentioned that it's better to use unstable version, I tried Debian sid (amd64) and still got problems with RcppGSL. That stand-alone test returns exit code 1 with message "Missing the following R library RcppGSL". And for commented tests in run-unit-test file the message is "Cannot use --stats-only with missing R libraries". Regards, Nadiya On Fri, Mar 24, 2017 at 3:32 AM, Andreas Tille <andr...@an3as.eu> wrote: > Hi Nadiya, > > thanks for your work on this. It seems you've hit a non-trival example > but that's no problem but rather a challenge, right? > > At first I've fixed debian/changelog. It seems you always called > > dch -i > > which is for each call bumping the Debian release. Please use the -i > option only once. Even better use > > dch --team > > since this adds the "Team upload" entry which marks the upload in a way > that lintian (the Debian policy checker) does not claim that the > changelog owner is not listed as Uploader in debian/control. > > Please git pull to see the result. > > On Thu, Mar 23, 2017 at 09:55:37PM -0700, Nadiya Sitdykova wrote: > > I've added tests of examples from here > > https://ginolhac.github.io/mapDamage/#a5 But only two of them works > fine. > > Hmm, I admit I get a strange error even here: > > mapDamage -i rescale_test/pe_test/pe.sam -r rescale_test/pe_test/ref.fa > Started with the command: /usr/bin/mapDamage -i > rescale_test/pe_test/pe.sam -r rescale_test/pe_test/ref.fa > Reading from 'rescale_test/pe_test/pe.sam' > Writing results to 'results_pe/' > pdf results_pe/Fragmisincorporation_plot.pdf generated > No length distributions are available, plotting length distribution only > works for single-end reads > Error: Seqtk failed: [Errno 2] No such file or directory > > I applied all patches via > > quilt push -a > > and checked for occurences of seqtk via: > > mapdamage(master) $ grep -Riw Seqtk | grep -v -e "^\." -e "^debian" > mapdamage/composition.py: path_to_seqtk = mapdamage.rscript.construct_ > path("seqtk",folder="seqtk") > mapdamage/composition.py: sys.stderr.write("Error: Seqtk failed: > %s\n" % (error,)) > bin/mapDamage: fpath_seqtk = '/usr/bin/seqtk' > bin/mapDamage: sys.stderr.write("Seqtk executable not accessible; > mapDamage has not\n" > > So it seems that in mapdamage/composition.py the path to seqtk is not > properly assembled. Would you mind checking this? > > > Other two "Cannot use --<option> with missing R-libraries", so it seems > > they need recommended r-cran-rcppgsl package. I created simple > stand-alone > > test with this package in depends to demonstrate that something goes > wrong > > with installing RcppGSL. I looked at the source code here > > https://anonscm.debian.org/cgit/debian-med/mapdamage.git/ > tree/mapdamage/Rscripts/stats/checkLibraries.R > > and > > it looks like after package installation "library(RcppGSL)" doesn't load > > library correctly. > > Hmmm, GSL rings a bell for me. There was a gsl library transistion. > Are you using a current Debian testing or unstable system? If not that > might be the cause of the issue. May be you explain more verbosely > what exactly you mean by "doesn't load library correctly"? > > I get > > $ mapDamage --check-R-packages > All R packages are present > > > After checking mapdamage/rscript.py what R packages are really checked I > added some R packages as real Depends. I personally follow the strategy > to use Depends if a package is needed to run the full test suite. While > I actually learned from your commits that you can work around this via > "needs-recommends" (its nice to learn when mentoring ;-) ) I'm sure > users really want to have the full functionality. > > In summary please do the following: > > 1. Check why seqtk is not found in mapdamage/composition.py > my guess is that the current quilt patch is incomplete. > > 2. If the R test keeps on failing please provide more information > > Thanks again for your work on this > > Andreas. > > PS: Regarding the time delay you mentioned in your other mail: That's > fine - we have team members in different time zones. :-) > > -- > http://fam-tille.de > >
