Bug#962553: gffread: autopkgtest needs update for new version of gff2aplot: warning on stderr
Control: tags -1 moreinfo
Control: severity -1 important
Control: tags -1 unreproducible
Hi Andreas,
I tried reproducing this bug but all tests simply pass for me, even when I
manually install the specified versions.
The compression doesn't seem to have any effect on the tests for me.
Regards,
Pranav
On Tue, Jul 21, 2020 at 3:46 PM Andreas Tille wrote:
> Hi Pranav,
>
> On Mon, Jul 06, 2020 at 12:06:06PM +0300, Adrian Bunk wrote:
> >
> > The actual problem is:
> > Due to the dh compat bump in gff2aplot the gffread autopkgtest runs
> > additional tests, and on two of these gffread is segfaulting.
>
> I've checked the debdiff of the two binary packages in question
> which are affected by the debhelper compat bump:
>
> $ debdiff gff2aplot_2.0-11_amd64.deb gff2aplot_2.0-12_amd64.deb
> [The following lists of changes regard files as different if they have
> different names, permissions or owners.]
>
> Files in second .deb but not in first
> -
> -rw-r--r-- root/root /usr/share/doc/gff2aplot/examples/mhcregion/README
> -rw-r--r-- root/root
> /usr/share/doc/gff2aplot/examples/mhcregion/hs-mm.gff
> -rw-r--r-- root/root
> /usr/share/doc/gff2aplot/examples/mhcregion/hs-mm.sim
> -rw-r--r-- root/root
> /usr/share/doc/gff2aplot/examples/mhcregion/hs-mm.sim.gff
> -rw-r--r-- root/root
> /usr/share/doc/gff2aplot/examples/mhcregion/hs-mm.tblastx.gff
> -rw-r--r-- root/root /usr/share/doc/gff2aplot/examples/mhcregion/hs.fa
> -rw-r--r-- root/root /usr/share/doc/gff2aplot/examples/mhcregion/kk.sim
> -rw-r--r-- root/root /usr/share/doc/gff2aplot/examples/mhcregion/mm.fa
> -rw-r--r-- root/root /usr/share/doc/gff2aplot/examples/splice_sites/
> KCRB.AG.hs-mm.gff
> -rw-r--r-- root/root /usr/share/doc/gff2aplot/examples/splice_sites/
> KCRB.GT.hs-mm.gff
> -rw-r--r-- root/root /usr/share/doc/gff2aplot/examples/splice_sites/
> KCRB.hs.gb
> -rw-r--r-- root/root /usr/share/doc/gff2aplot/examples/splice_sites/
> KCRB.mm.gb
> -rw-r--r-- root/root
> /usr/share/doc/gff2aplot/examples/splice_sites/README
> -rw-r--r-- root/root /usr/share/doc/gff2aplot/examples/wublast/README
> -rw-r--r-- root/root /usr/share/doc/gff2aplot/examples/wublast/
> taf6.hs.gene.gb
> -rw-r--r-- root/root /usr/share/doc/gff2aplot/examples/wublast/
> taf6.mm.gene.gb
> -rw-r--r-- root/root
> /usr/share/doc/gff2aplot/examples/wublast/taf6.mmhs.genomic.blastn
> -rw-r--r-- root/root
> /usr/share/doc/gff2aplot/examples/wublast/taf6.mmhs.genomic.blastn.full.gff
> -rw-r--r-- root/root
> /usr/share/doc/gff2aplot/examples/wublast/taf6.mmhs.genomic.tblastx.aplot.gff
> -rw-r--r-- root/root
> /usr/share/doc/gff2aplot/examples/wublast/taf6.mmhs.genomic.tblastx.gff
>
> Files in first .deb but not in second
> -
> -rw-r--r-- root/root
> /usr/share/doc/gff2aplot/examples/mhcregion/README.gz
> -rw-r--r-- root/root
> /usr/share/doc/gff2aplot/examples/mhcregion/hs-mm.gff.gz
> -rw-r--r-- root/root
> /usr/share/doc/gff2aplot/examples/mhcregion/hs-mm.sim.gff.gz
> -rw-r--r-- root/root
> /usr/share/doc/gff2aplot/examples/mhcregion/hs-mm.sim.gz
> -rw-r--r-- root/root
> /usr/share/doc/gff2aplot/examples/mhcregion/hs-mm.tblastx.gff.gz
> -rw-r--r-- root/root
> /usr/share/doc/gff2aplot/examples/mhcregion/hs.fa.gz
> -rw-r--r-- root/root
> /usr/share/doc/gff2aplot/examples/mhcregion/kk.sim.gz
> -rw-r--r-- root/root
> /usr/share/doc/gff2aplot/examples/mhcregion/mm.fa.gz
> -rw-r--r-- root/root /usr/share/doc/gff2aplot/examples/splice_sites/
> KCRB.AG.hs-mm.gff.gz
> -rw-r--r-- root/root /usr/share/doc/gff2aplot/examples/splice_sites/
> KCRB.GT.hs-mm.gff.gz
> -rw-r--r-- root/root
> /usr/share/doc/gff2aplot/examples/splice_sites/KCRB.hs.gb.gz
> -rw-r--r-- root/root
> /usr/share/doc/gff2aplot/examples/splice_sites/KCRB.mm.gb.gz
> -rw-r--r-- root/root
> /usr/share/doc/gff2aplot/examples/splice_sites/README.gz
> -rw-r--r-- root/root /usr/share/doc/gff2aplot/examples/wublast/README.gz
> -rw-r--r-- root/root
> /usr/share/doc/gff2aplot/examples/wublast/taf6.hs.gene.gb.gz
> -rw-r--r-- root/root
> /usr/share/doc/gff2aplot/examples/wublast/taf6.mm.gene.gb.gz
> -rw-r--r-- root/root
>
> /usr/share/doc/gff2aplot/examples/wublast/taf6.mmhs.genomic.blastn.full.gff.gz
> -rw-r--r-- root/root
> /usr/share/doc/gff2aplot/examples/wublast/taf6.mmhs.genomic.blastn.gz
> -rw-r--r-- root/root
>
> /usr/share/doc/gff2aplot/examples/wublast/taf6.mmhs.genomic.tblastx.aplot.gff.gz
> -rw-r--r-- root/root
> /usr/share/doc/gff2aplot/examples/wublast/taf6.mmhs.genomic.tblastx.gff.gz
>
> Control files: lines which differ (wdiff format)
>
> Installed-Size: [-647-] {+1451+}
> Version: [-2.0-11-] {+2.0-12+}
>
>
> So the files are not compressed now any more. Could you have
> a look at the consequences this has on the test in gffread?
>
> Kind regards
>
> Andreas.
>
> --
> http://fam-tille.de
>
ᐧ
Bug#963299: Some issues with d/rules in sniffles
Hi,
I've (apparently) managed to fix this bug although I'm not sure what the
original code was trying to do.
Originally, d/rules:
INCLUDE_PATHS = /usr/include/bamtools
space=
space+=
override_dh_auto_configure:
dh_auto_configure -- \
-DCMAKE_INCLUDE_PATH="$(subst $(space),:,$(strip $(INCLUDE_PATHS)))"
When the build was attempted on bare metal with dpkg-buildpackage,
DCMAKE_INCLUDE_PATH=/usr/include/bamtools
which is right.
However, everytime build was attempted inside a chroot with sbuild,
DCMAKE_INCLUDE_PATH=/usr/include/bamtools:
and the colon at the end is apparently what results in this error inside a
chroot.
After changing d/rules to
INCLUDE_PATHS=/usr/include/bamtools
override_dh_auto_configure:
dh_auto_configure -- \
-DCMAKE_INCLUDE_PATH="${INCLUDE_PATHS}"
the error goes away and the right files are included, outside as well as
inside a chroot.
I've committed this change but I'm not sure what the original code was
trying to do so please take a look and sponsor if everything is right.
Regards,
Pranav
ᐧ
Bug#962553: Bugfix: Patched gff2aplot
Hi, This error occurs because gffread complains about tabs in comments for some reason, even though GFF parsers are supposed to ignore all the lines that start with #. Since these lines are human-readable comments anyway, replacing tabs with spaces seems like the easiest fix. I've patched gff2aplot and autopkgtests pass now. Please take a look. Regards, Pranav ᐧ
Bug#960760: Fixed Bug#960760: tree-puzzle FTBFS on !amd64: test failures
Hi, I've pushed a patch for tree-puzzle to fix #960760. Please review. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960760 https://salsa.debian.org/med-team/tree-puzzle Regards, Pranav ᐧ
Bug#960760: tree-puzzle FTBFS on !amd64: test failures
Hi Andreas, Yes definitely, this is long overdue. I have a report due for submission tonight, so I'll get to this tomorrow for sure. Regards, Pranav On Tue, 9 Jun, 2020, 7:41 PM Andreas Tille, wrote: > Hi Pranav, > > since you dealt with tests in this package could you please have > a look? > > Kind regards > > Andreas. > > On Sat, May 16, 2020 at 02:50:12PM +0300, Adrian Bunk wrote: > > Source: tree-puzzle > > Version: 5.3~rc16+dfsg-1 > > Severity: serious > > Tags: ftbfs > > > > Based on the "Important remark" below, test failures shouldn't be fatal. > > This would also make them not suitable for autopkgtest. > > > > > > https://buildd.debian.org/status/package.php?p=tree-puzzle=sid > > > > ... > > FAIL: qp-hky-rhet-nucl > > == > > > > > > Testing: nucleotide data, HKY, rate heterogeneity, quartet puzzling > (qp-hky-rhet-nucl) > > 327c327 > > < Dasyurus 3 0.1 0.00268 11 0.07879 0.07178 > > --- > > > Dasyurus 3 0.1 0.00141 11 0.07879 0.07178 > > FAIL qp-hky-rhet-nucl.test (exit status: 1) > > > > FAIL: qp-hky-rhet-clock-nucl > > > > > > > > Testing: nucleotide data, HKY, clock, rate heterogeneity, quartet > puzzling (qp-hky-rhet-clock-nucl) > > 327c327 > > < Dasyurus 3 0.1 0.00268 11 0.07879 0.07178 > > --- > > > Dasyurus 3 0.1 0.00141 11 0.07879 0.07178 > > FAIL qp-hky-rhet-clock-nucl.test (exit status: 1) > > > > FAIL: qp-jtt-rhet-prot > > == > > > > > > Testing: protein data, JTT, rate heterogeneity, quartet puzzling > (qp-jtt-rhet-prot) > > 295c295 > > < HBA_HUMAN 3 0.01975 0.02293 10 0.74671 0.14184 > > --- > > > HBA_HUMAN 3 0.01975 0.02294 10 0.74671 0.14184 > > FAIL qp-jtt-rhet-prot.test (exit status: 1) > > > > FAIL: qp-jtt-rhet-clock-prot > > > > > > > > Testing: protein data, JTT, clock, rate heterogeneity, quartet puzzling > (qp-jtt-rhet-clock-prot) > > 295c295 > > < HBA_HUMAN 3 0.01975 0.02293 10 0.74671 0.14184 > > --- > > > HBA_HUMAN 3 0.01975 0.02294 10 0.74671 0.14184 > > FAIL qp-jtt-rhet-clock-prot.test (exit status: 1) > > > > FAIL: ut-pure-prot > > == > > > > > > Testing: protein data, default model, user tree evaluation (ut-pure-prot) > > 178c178 > > < HBB_HORSE 2 0.12686 0.03876 9 0.1 0.00105 > > --- > > > HBB_HORSE 2 0.12686 0.03876 9 0.1 0.00100 > > 218c218 > > < HBB_HUMAN 1 0.04915 0.03158 8 0.28347 0.08777 > > --- > > > HBB_HUMAN 1 0.04915 0.03158 8 0.28347 0.08778 > > 258c258 > > < HBB_HORSE 2 0.12653 0.03874 9 0.12334 0.15663 > > --- > > > HBB_HORSE 2 0.12653 0.03874 9 0.12334 0.15661 > > FAIL ut-pure-prot.test (exit status: 1) > > > > FAIL: cons-pure-prot > > > > > > > > Testing: protein data, default model, consensus construction > (cons-pure-prot) > > 230c230 > > < HBB_HUMAN 1 0.04834 0.03148 8 0.28040 0.08745 > > --- > > > HBB_HUMAN 1 0.04834 0.03148 8 0.28040 0.08746 > > FAIL cons-pure-prot.test (exit status: 1) > > > > SKIP: build-remark > > == > > > > > > *** > > *** !!! Important remark !!! > > *** > > *** Please note that only the output file *.puzzle is checked > > *** for identity. The overall precision reached in the program > > *** is heavily dependent on the compiler as well as the optimization > > *** level (-O) used to compile the executable. > > *** Hence, even if tests are marked as failed this might just be > > *** due to differences in less significant digits caused by rounding > > *** errors from less acurate computations for the sake of faster > > *** running times. (If you want to be sure about this please refer > > *** to your compiler's manual!) > > *** > > *** Please check the output file differences which are printed during > the tests. > > *** The template files which the results are checked against have been > > *** generated with TREE-PUZZLE 5.2 compiled with GCC version > 3.3-20030226 > > *** and default compiler flags '-g -O2' and using the SPRNG random > number > > *** generator. > > *** > > > > SKIP build-remark (exit status: 77) > > > > > > > Testsuite summary for tree-puzzle 5.3.rc16 > > > > > # TOTAL: 19 > > # PASS: 11 > > # SKIP: 2 > > # XFAIL: 0 > > # FAIL: 6 > > # XPASS: 0 > > # ERROR: 0 > > > > > See tests/test-suite.log > > > > > make[5]: *** [Makefile:563: test-suite.log] Error 1 > > make[5]: Leaving directory '/<>/tests' > > > > ___ > > Debian-med-packaging mailing list > >
Bug#961013: diamond-aligner: Diamond faill with the error: Assertion `index >= 0 && index < size()' failed.
Hi, I've narrowed the issue down to one (or a few) sequences. Basically this error occurs whenever a query sequence is less than five nucleotides (and is independent of the length of sequences in the database file). Besides, it's not specific to the Debian package. I encountered the same error when I compiled from the upstream source, but it went away when I downloaded the compiled binary, so it's probably something to do with the way it is compiled. I've reported this on the Github issue page here <https://github.com/bbuchfink/diamond/issues/351> along with the smallest dataset that can be used to reproduce this issue. Maybe now we wait for upstream to take a look? Regards, Pranav ᐧ On Fri, May 22, 2020 at 3:37 AM Andreas Tille wrote: > On Thu, May 21, 2020 at 06:33:05PM +0530, Pranav Ballaney wrote: > > Yes, I've been able to reproduce and roughly pin point the issue, but it > > needs some more work before it's solved. > > That's pretty good news. Just take the time you need. > > Thanks for your effort > > Andreas. > > -- > http://fam-tille.de >
Bug#961494: bowtie2: please make the build reproducible
Hi everyone, The tests pass for me as well. autopkgtest [22:46:32]: test binary-run: - - - - - - - - - - results - - - - - - - - - - binary-run PASS autopkgtest [22:46:32]: summary check-wo-arguments PASS indexing-ref-genome PASS binary-run PASS Regards, Pranav ᐧ On Mon, May 25, 2020 at 8:49 PM Nilesh Patra wrote: > > > On Mon, 25 May 2020 at 20:10, Andreas Tille wrote: > >> Hi Chris, >> >> On Mon, May 25, 2020 at 10:49:28AM +0100, Chris Lamb wrote: >> > This should have read: >> > >> > Whilst you do patch out -fdebug-prefix-map in >> > debian/patches/reproducible.patch, you also need to filter >> > -ffile-prefix-map. >> >> I've tried this in Git[1] but the resulting bowtie2 package fails the >> autopkgtest in my pbuilder environment. I remember issues with >> autopkgtest in pbuilder before and I suspect this might be the case >> here as well. However, before I really upload I'd invite others to >> have a look. >> > > I can confirm that this passes for me. > > autopkgtest [20:46:44]: test binary-run: [--- > autopkgtest [20:46:45]: test binary-run: ---] > autopkgtest [20:46:45]: test binary-run: - - - - - - - - - - results - - > - - - - - - - - > binary-run PASS > autopkgtest [20:46:45]: summary > check-wo-arguments PASS > indexing-ref-genome PASS > binary-run PASS > > Just maybe, this is a false positive again, at your end. > > [1] >> https://salsa.debian.org/med-team/bowtie2/-/commit/97052bc2de1b271f368dd8415cfafde5356e2fe8 > > > Kind regards, > Nilesh >
Bug#960368: Patch to avoid segfault in kallisto
Hi, I investigated the segfault issue in kallisto, and found a fix for it. Details can be found at https://github.com/pachterlab/kallisto/issues/254#issuecomment-629546051 I've written a patch to avoid the segfault, for the time being, until upstream fixes it. Please take a look. https://salsa.debian.org/med-team/kallisto Regards, Pranav ᐧ
Bug#806214: RFS: Tree-puzzle tests updated
Hi, I've confirmed from upstream for tree-puzzle that the failing tests were only due to formatting and rounding changes in the tests/check* files. I've pushed a patch to update these files and also added autopkgtests. Please review and sponsor. https://salsa.debian.org/med-team/tree-puzzle Regards, Pranav ᐧ
Bug#958560: ITP: r-bioc-htsfilter -- Filter replicated high-throughput transcriptome sequencing data
Package: wnpp Severity: wishlist Subject: ITP: r-bioc-htsfilter -- Filter replicated high-throughput transcriptome sequencing data Package: wnpp Owner: Pranav Ballaney Severity: wishlist * Package name: r-bioc-htsfilter Version : 1.26.0 Upstream Author : Andrea Rau, Melina Gallopin, Gilles Celeux, and Florence Jaffrezic * URL : https://bioconductor.org/packages/HTSFilter/ * License : Artistic-2.0 Programming Lang: GNU R Description : Filter replicated high-throughput transcriptome sequencing data This package implements a filtering procedure for replicated transcriptome sequencing data based on a global Jaccard similarity index in order to identify genes with low, constant levels of expression across one or more experimental conditions. Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-bioc-htsfilter ᐧ
Bug#954511: Can someone habe a look at bioperl-run in connection with kalign (was: bioperl-run is marked for autoremoval from testing]
Hi, Yes, Kalign is on v3 now. I've pushed some patches to fix this bug. All build-time tests pass now. Autopkgtests don't, however, but that issue seems to be unrelated. Please take a look at https://salsa.debian.org/med-team/bioperl-run and verify the patches. This is my first time working with quilt patches so apologies if I did something wrong. Regards, Pranav On Mon, Mar 30, 2020 at 8:23 PM Christopher Fields wrote: > I have seen per exit codes of 256 for other bioperl-run wrappers in the > past where the application API changed (constant game of playing catchup > unfortunately). That seems to be the case here based on the error. Is > kalign is now at v3? > > chris > > On 3/30/20, 2:57 AM, "Andreas Tille" wrote: > > Control: tags -1 help > > Hi, > > currently bioperl-run fails. I think the issue is: > > > > # Failed test 'Code tested only on kalign versions >= 2' > > # at t/Kalign.t line 23. > > # got: '' > > # expected: '1' > > [2020-03-22 03:18:02] : ERROR : Input alignment format could not > be detected. (rwalign.c line 314) > > [2020-03-22 03:18:02] : ERROR : Function > "detect_alignment_format(b, )" failed. (rwalign.c line 187) > > [2020-03-22 03:18:02] : ERROR : Function "tmp_msa = > read_input(param->infile[i],tmp_msa)" failed. (run_kalign.c line 383) > > [2020-03-22 03:18:02] : ERROR : Function "run_kalign(param)" > failed. (run_kalign.c line 353) > > > > - WARNING - > > MSG: Kalign call crashed: 256 [command /usr/bin/kalign -in > t/data/cysprot.fa -out /tmp/ilV8fEWBHj/nJrv_GQaDU] > > > but please double check. Could someone have a look please? > > Kind regards > >Andreas. > > - Forwarded message from Debian testing autoremoval watch < > nore...@release.debian.org> - > > Date: Mon, 30 Mar 2020 04:39:17 + > From: Debian testing autoremoval watch > To: bioperl-...@packages.debian.org > Subject: bioperl-run is marked for autoremoval from testing > > bioperl-run 1.7.3-3 is marked for autoremoval from testing on > 2020-05-05 > > It is affected by these RC bugs: > 954511: bioperl-run: FTBFS: dh_auto_test: error: perl Build test > --verbose 1 returned exit code 255 > > > ___ > Debian-med-packaging mailing list > debian-med-packag...@alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging > > - End forwarded message - > > -- > http://fam-tille.de > > > ᐧ
Bug#909716: Request for sponsoring changes in idba
Hi Andreas, On Tue, 10 Mar, 2020, 9:21 PM Andreas Tille, wrote: > > Fine. That works. Sorry when I have given a bit short-cutted advise. > I've completed the long description. > Oh sorry I missed. Actually I changed it at first but it didn't work so I went back and forth a few times and forgot to complete it. In my commit 6cff0c2377861eb179d4ec06514df75df1323510 I tried to fix this > but did not test which I'll leave you for an exercise. ;-) > Thanks, this worked, but initially it didn't compile. The error was that it couldn't find any *.1 files in debian/idba and debian/idba-extra. However, when I renamed the two folders to idba-man and idba-extra-man, it suddenly worked. Do you have any ideas why this was so? > When doing so I stumbled upon the script run-unittest.py which I think > should not end up in /usr/bin. I installed it into docs and your second > exercise could be to check whether it really does some sensible testing > at all. As far as I can see it is just triggering the build time test > but it does not look as if it be useful to install on users machines. > Even if it would make sense the name /usr/bin/run-unittest.py is way to > generic and should be avoided. Same with /usr/bin/scan.py - please > check whether this script makes sense in /usr/bin it should be probably > renamed (to something like idba_scan.py). Otherwise it should also go > to /usr/share/doc/idba (or left out fully). > Yes, it should definitely not go to debian/bin, sorry. Line 17 in debian/rules [1] says, "for the moment the role of these scripts is totally unknown but they do not seem to be necessary," and proceeds to copy run-unittest.py, scan.py, validate_blat and validate_blat_parallel to usr/lib/idba. I tried commenting out these lines, and the package seems to work just fine. They seem to be required only during compilation and testing, so they probably shouldn't be installed as binaries in the final user installation. Maybe we could let them be in the lib folder? I'm not sure, however. Please take a look and let me know if I should change it to docs. > > I have also changed the test files now. Only a few necessary files are > > included, and the rest are generated during testing. > > That's really good! The only think I'm missing now is that we should > always mention the origin where the data were obtained from (may be in > a script calling wget for downloading). It makes also sense to drop > some note about the license of these files. > I have added a file called data-source.sh in debian/tests/test-data. Is this the right way to do it? Also, I obtained the data from their research papers about these tools. What kind of license would be applicable in this case? And where do I get the license from? > > Let me know if I missed anything, otherwise please review and sponsor > these > > changes. > > What you did is basically correct and extremely helpful to finalise the > autopkgtest. Please inspect my recent commits and try to provide the > missings I mentioned above in this mail. I added a few examples by extending the debian/createmanpages script. > I'd perfectly accept some kind of "lazyness" here. I would not mind > uploading the current incomplete status despite of the lintian warnings. > I usually decide according to the "importance" of the tool that needs a > manpage. My motivation was to get "the first three in list" and also > the ones we are using in autopkgtest. Feel free to decide whether you > want a complete set of manpages or not. Okay. I think the set of manpages we have should be enough, given that the other tools aren't too important. Thanks for the intro to dh_install, man pages and documentation about packages. Please let me know if any more work is required on this package. Regards, Pranav ᐧ
Bug#909716: Request for sponsoring changes in idba
Hi Andreas, On Sun, Mar 8, 2020 at 12:54 PM Andreas Tille wrote: > Hi Pranav, > I hope you are happy with your result. > Thank you, they went quite well. May be adding some binary package idba-extra (or some better name you > might find) to ship these additional tools that might be not needed in > every day use but might be helpful anyway for some use case - for > instance testing the package. > > > Also, would it be possible to have some programs available only during > > testing, but not in the finall installation? Then we could run sim_reads > > that way and avoid all the static data. > > Yes, for instance in an extra binary package. While we could even run > autopkgtest inside a compiled source tree I personally prefer to ship > every tool inside some binary Debian package to enable users reproducing > the test results on their installation. > Yes, this makes sense. I have added another package called idba-extra. > Than you do > > git mv debian/install debian/idba.install > git mv debian/manpages debian/idba.manpages > > (which is strictly speaking redundant since by default debian/install > and debian/manpages are affecting the first binary package - but I > consider this better) and create a > > $EDITOR debian/idba-extra.install > > package listing all tools you want to install into this package. > One small problem I ran into: There was no debian/install file originally, so I couldn't figure out how it is that these files are being copied. Is it something to do with make install? I've added debian/idba.install and debian/idba-extra.install, and everything works as expected. Although, the following warnings are generated during testing. dh_missing: warning: usr/bin/idba_tran exists in debian/tmp but is not installed to anywhere dh_missing: warning: usr/bin/validate_blat_parallel exists in debian/tmp but is not installed to anywhere dh_missing: warning: usr/bin/validate_blat exists in debian/tmp but is not installed to anywhere dh_missing: warning: usr/bin/idba_ud exists in debian/tmp but is not installed to anywhere dh_missing: warning: usr/bin/scan.py exists in debian/tmp but is not installed to anywhere dh_missing: warning: usr/bin/idba_hybrid exists in debian/tmp but is not installed to anywhere dh_missing: warning: usr/bin/run-unittest.py exists in debian/tmp but is not installed to anywhere dh_missing: warning: usr/bin/idba exists in debian/tmp but is not installed to anywhere Please check debian/*.install and see if these are right. I have also changed the test files now. Only a few necessary files are included, and the rest are generated during testing. Let me know if I missed anything, otherwise please review and sponsor these changes. > Hope this short intro is helpful. > It was very helpful, indeed. I have a few more queries, though. I was trying to find more information about the structure of packages and I found these two guides: https://www.debian.org/doc/manuals/packaging-tutorial/packaging-tutorial.en.pdf https://www.debian.org/doc/manuals/maint-guide/dother.en.html Are these okay, or would you recommend some other resource? Also, now that we have included some new programs in the idba-extra package, how can I generate man pages for them? I noticed that it is the debian/*.1 files that correspond to manpages, and are generated using help2man. But as far as I understand, help2man needs the executable, which is produced only inside the testing chroot. So, do I run help2man inside the chroot, or is there another way? And does anything else need to be done, when a new package is added? Please reply whenever it is convenient for you. Regards, Pranav ᐧ
Bug#909716: Request for sponsoring changes in idba
Hi Andreas, My mid-sem exams are over now, and I can resume work on idba. On Mon, Feb 24, 2020 at 2:21 PM Andreas Tille wrote: I'm now realising that idba build system builds a lot of other tools > inside $(CURDIR)/bin which might (or might not?) be sensible to install. > Yes, there are over 20 tools that come with this package. I've been trying to find documentation, but haven't had any luck so far. Did you find any while packaging? Otherwise we could email the original author and ask for help, because without proper documentation it will be difficult to decide which tools to include in the binary. >I am being able to use it if I build the package from source on > >my machine, but within the testing chroot, autopkgtest reports that > this > >command is not found. > > (UNTESTED!) Please have a look at commit > 133e974096b40aedc7108258b286f74296894f3a where I've set PATH to make sure > all binaries will be found. > > >If this command can be used while testing, the > >downloads required for testing will be reduced from the current 25MB > to a > >mere 1.5MB, because the rest of the data can be generated as required. > > I have not verified the test suite but it is not possible to download > anything while building the package since every package needs to be able > to build on a non-networked machine. So every download has to be > patched from the test suite anyway. > Sorry, I used an incorrect term here. By downloads I was talking only about the test data. For now, I have included it within debian/tests but if it is possible to run sim_reads during testing, it will reduce the data required for testing, because a lot of it can be generated using sim_reads and sim_reads_tran. Its way more sensible to provide all needed tools inside the package. > so please decide which of **all** the tools in $(CURDIR)/bin should end > up in the binary package. You can install these easily by for instance > adding a line like >bin/sim_readsusr/bin > to the file debian/install. > Thanks. Let's see if we can find documentation first, else I'll look into each program and try to figure out which ones to include. At first glance, it seems like sim_reads and sim_reads_tran were made only to generate data for testing, but I will look into this in depth (and other tools too) and get back to you about this. > >2. To copy the test_data to a temp folder inside the testing chroot, I > >have added an install file inside the debian folder. Is this the > right way > >to do it? > > In principle yes. However, if we really need to keep any large static > data files (instead of generating these) I would prefere to add an > additional > Architecture: all package (for instance named idba-data). The rationale is > that Architecture: any files are duplicated for every Debian architecture > which is not bloating the Debian ftpmirror network with duplicated files > but > also creates a lot of network traffic. That's why we split up those binar > independent files into a separate binary package. Moreover if the data are > not used to actually run the package we would also bloat user machines who > might just want to run idba in a cluster or so. > > In short: Please check prefere creation of the files in the test over > static > data. Having a few small files provided statically is fine, thought. > While I get the general idea, I don't exactly understand what Architecture: all and Architecture: any packages are. Could you provide a link to a resource about these? Also, would it be possible to have some programs available only during testing, but not in the finall installation? Then we could run sim_reads that way and avoid all the static data. > Provided that your time permits > >1. Decide about what executables in $(CURDIR)/bin should be installed 2. Generate as much data as possible 3. Check whether test suite tries to download anything and ignore > these tests or provide these data statically >4. If we need large static data files create an extra binary package > > Feel free to ask me about any of these steps if you might need any help! > I need some help regarding binary packages. How can I create one? Does it require adding a file or folder inside the idba repo, or is it another repo entirely? Thanks for the hints about dch and installing test files and tools. I'll keep these in mind. Regards, Pranav ᐧ
Bug#909716: Fwd: Request for sponsoring changes in idba
Just to keep it on the bug log as well. -- Forwarded message - From: Pranav Ballaney Date: Sun, Feb 23, 2020 at 3:07 PM Subject: Request for sponsoring changes in idba To: Hi, I have added autopkgtests for idba <https://salsa.debian.org/med-team/idba>. (Closes #909716 <https://bugs.debian.org/909716>) I need a few suggestions on how these tests can be improved. 1. The test data can be generated using the sim_reads command that comes with the package, but for some reason, it isn't installed when the package is built. I am being able to use it if I build the package from source on my machine, but within the testing chroot, autopkgtest reports that this command is not found. If this command can be used while testing, the downloads required for testing will be reduced from the current 25MB to a mere 1.5MB, because the rest of the data can be generated as required. For now, I have generated and added all the files manually, and included the code used to generate this data in a README file inside debian/tests/test_data, if it becomes possible to run these while testing at a later stage. 2. To copy the test_data to a temp folder inside the testing chroot, I have added an install file inside the debian folder. Is this the right way to do it? I have also updated the changelog (and marked the bug resolved) and added a README.test file inside debian. Please let me know if I missed out anything, and if not, please review and sponsor these changes. Regards, Pranav ᐧ ᐧ
Bug#909708: Working tests seem to exist for epcr
Hi Andreas, Thanks for looking into this and sending the guide about packages. I saw the CI page for epcr, and I have a follow-up query about the same - I had added autopkgtests to altree <https://salsa.debian.org/med-team/altree> the other day, and I've now added to loki <https://salsa.debian.org/med-team/loki> as well. So, can CI pages be built for these packages now? If yes, how? Also, is it that only after the CI pages are built, should the respective bugs (#909708 <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909708> and #909710 <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909710>) be marked closed? Or is it enough if the tests are working on my local machine, and can I close them right away? Thanks a lot for your help. Pranav On Tue, Feb 18, 2020 at 8:35 PM Andreas Tille wrote: > Hi Pranav, > > On Tue, Feb 18, 2020 at 05:07:44PM +0530, Pranav Ballaney wrote: > > I am Pranav Ballaney, a Biology and Computer Science student from India, > > and I have recently joined the Debian Med team, primarily writing > > autopkgtests for various packages. > > Thanks for the short introduction here and the interest into the Debian > Med GSoC / Outreachy project. > I tried running the tests present in this package, and they seem to > > work well on my local machine. Can this bug be marked closed now? > > Ahhh, perfectly correct. We simply forgot to close this bug in Debian > changelog the string "Closes: #909706" (see here[1]). > Since I'm new to Debian's development process, I'm not aware of the > > procedure to mark a bug resolved. Does it just involve sending a mail to > > 909706-cl...@bugs.debian.org? > > Exactly. I'm doing this hereby (in CC). > > > I would really appreciate if someone could look into this for me. If any > > more work is needed, I would be happy to work on it. > > No, you have properly analysed the situation - which despite beeing > simple is very helpful anyway. > > BTW, to check whether the existing tests are running nicely you could > have checked here the CI page of the package[2]. I'm just mentioning > this since it might be helpful for other tests you might develop in > future. > > > Thanks and regards, > > Thanks to you for spotting this issue > >Andreas. > > > [1] https://www.debian.org/doc/manuals/developers-reference/pkgs.html > [2] https://ci.debian.net/packages/e/epcr/ > > -- > http://fam-tille.de > ᐧ
Bug#909706: Working tests seem to exist for epcr
Hello, I am Pranav Ballaney, a Biology and Computer Science student from India, and I have recently joined the Debian Med team, primarily writing autopkgtests for various packages. I tried running the tests present in this package, and they seem to work well on my local machine. Can this bug be marked closed now? Since I'm new to Debian's development process, I'm not aware of the procedure to mark a bug resolved. Does it just involve sending a mail to 909706-cl...@bugs.debian.org? I would really appreciate if someone could look into this for me. If any more work is needed, I would be happy to work on it. Thanks and regards, Pranav ᐧ
Bug#909710: Procedure for closing this bug
Hi, I have added some autopkgtests to this package, and they seem to work well on my local machine. Since this was my first time working with Debian, I'm not aware of the procedure to mark bugs resolved. Is there a testing process where the code that I have committed will be checked, and only then can it be marked resolved? Or can I just email 909710-cl...@bugs.debian.org and it will be marked closed? Thanks and regards, Pranav ᐧ
