Re: SIMDe use in Debian's MMseqs2
Here's a version of Debian's SIMD Everywhere patch as a pull request for MMseqs2 https://github.com/soedinglab/MMseqs2/pull/309 On Fri, May 8, 2020 at 9:15 PM Michael Crusoe wrote: > [replying on the debian-med list with permission. Please keep Martin and > Milot CC'd as they do not subscribe] > > On Fri, May 8, 2020 at 7:36 PM Milot Mirdita wrote: > >> Hi Michael, >> >> I am a developer on the MMseqs2 team and I saw your tweet regarding the >> AWS ARM64 machines earlier and checked on Debian Salsa if it would be a lot >> of work enabling ARM64 support with the next release as we worked on that >> recently. >> > > Hey Milot, thanks for your email! > > I saw that Debian's MMseqs2 now uses SIMDe to abstract away different >> architectures. While this is a very cool technical achievement, I am very >> uncomfortable with it without being properly integrated into and monitored >> by our CI regression testing. >> >> During ARM64 development I found that there are a lot of subtle issues >> that can result in differing sensitivity between architectures (e.g. >> ARM64's default unsigned char type causes issues, there are many crashes on >> 32-bit ARM). I am also worried that our two most important platforms >> (SSE4.1 and AVX2) might suffer from performance regressions. >> > > Interesting! On Debian we have to provide binaries that respect the > architecture baseline. That means no SSE-, SSE2-, only binaries on > i386/i686 and no SSE3+ only binaries on AMD64. So that's why we compile > mmseqs2 multiple times, so there is a version that doesn't violate the > baseline, along with versions that should match the highest level of SIMD > support available on the user's CPU. > > https://salsa.debian.org/med-team/mmseqs2/-/blob/master/debian/rules#L22 > > > https://salsa.debian.org/med-team/mmseqs2/-/blob/master/debian/bin/simd-dispatch > > >> >> We will have ARM64 and hopefully also PPC64LE support in the next >> release. I would suggest to either wait and use our upstream code, or >> submit a PR with your changes to us and see how we can integrate everything >> correctly. >> > > Sure, happy to send the patches! I meant to, but hadn't gotten around to > it yet > > https://wiki.debian.org/SIMDEverywhere#Packages_Status > > >> >> Also I would be very glad if you could integrate the full regression >> suite to spot if all architectures produce consistent results. You can run >> the regression by calling from the repository: >> git submodule update --init >> ./util/regression/run_regression.sh ./path-to-mmseqs-binary >> scratch-directory >> > > Oh yeah, would love to! Except we need all the upstream sources in a > single tarball, which git submodules + GitHub releases makes difficult. So > if you can add a pure source (with all git submodules) tarball to > https://github.com/soedinglab/MMseqs2/releases that would be appreciated! > > >> >> We had refactored this test suite to make it as easy as possible to use >> for Shayan who initially had proposed to package MMseqs2 for Debian. The >> test subfolder is badly named and contains scratch scripts for feature >> development. They don't do anything useful for testing such as finding >> performance or sensitivity drops. >> > > Noted. > > >> Thanks for your work and best regards, >> > > Thank you for sharing your work under a F/OSS license and for your > contributions to Open Science! > > >> Milot >> > > > -- > Michael R. Crusoe > -- Michael R. Crusoe
Re: Packaging libsis-jhdf5-java -- help needed
Hi Andreas, Le 08/05/2020 à 22:51, Andreas Tille a écrit : > Hi Pierre, > > On Fri, May 08, 2020 at 10:24:47PM +0200, Pierre Gruet wrote: >> >> Absolutely. This is part of the complementary tasks I was planning to do >> (my Salsa push of yesterday was only to fix the RC bug). h5ar was not in >> the previous packaging of libsis-jhdf5-java. > > If you think you might be able to care for the h5ar binary issue in the > next couple of days I would delay the upload to fix the RC bug. I guess > this will not have any practical drawback if the propagation of this > package to testing will be delayed some more days. > Fine then, we can delay the upload as I plan to care for h5ar those days :-) > > [...] > > I can confirm that you can't prevent learning something when dealing > with Debian packages. ;-) > I guess this is one of the great things about packaging! > > Kind regards > > Andreas. > Have a nice day, Pierre
Re: RFS paml - fixed #957659
Hi Étienne, On Fri, May 08, 2020 at 02:27:37PM +0200, Étienne Mollier wrote: > I fixed another Gcc-10 FTBFS, for the "paml" package this time, > and took this opportunity to run routine-update. Thanks a lot. > Manual pages > are still missing though. Actually, I have no clue how are > supposed to be used these programs, so it may be better if > someone having little background in phylogenic analysis has a > look at this. I tend to use help2man but as you might have noticed this does not work here. > I have not forwarded the patch for the moment, since reporting > bugs requires posting in a Google Group that forbids contact > through email, and I have no Google account for the moment, at > least none usable to my knowledge. :( IMHO if upstream makes it very hard to be contacted our effort we should do should not be exagerated. Kind regards Andreas. -- http://fam-tille.de
Re: RFS paml - fixed #957659
Hi Andreas, Andreas Tille, on 2020-05-09 15:01:33 +0200: > On Fri, May 08, 2020 at 02:27:37PM +0200, Étienne Mollier wrote: > > I fixed another Gcc-10 FTBFS, for the "paml" package this time, > > and took this opportunity to run routine-update. > > Thanks a lot. You're welcome, thanks for the upload. > > I have not forwarded the patch for the moment, since reporting > > bugs requires posting in a Google Group that forbids contact > > through email, and I have no Google account for the moment, at > > least none usable to my knowledge. :( > > IMHO if upstream makes it very hard to be contacted our effort > we should do should not be exagerated. I'm not entirely sure I understood your opinion, but if there are more projects requiring a Google Account to contact upstream, then I'll probably reconsider getting one. After all, there are so many projects on Github today, that I ended up opening an account last month just to allow myself interacting with upstream. It seems to have been a good move given the positive reactions I received on that side so far. :) Kind Regards, -- Étienne Mollier Fingerprint: 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d Help find cures against the Covid-19 ! Give CPU cycles: * Rosetta@home: https://boinc.bakerlab.org/rosetta/ * Folding@home: https://foldingathome.org/ signature.asc Description: PGP signature
RFS: cgview
Hi, I've added autopkgtests to cgview. Since the output is an image, I haven't compared it to a reference - is that alright? If not, how do we usually test packages like this? I tried running a diff but that reported the files to be different, even though they were visually the same. Please take a look and let me know if any additional steps are required. https://salsa.debian.org/med-team/cgview Regards, Pranav ᐧ
Re: RFS paml - fixed #957659
On Sat, May 09, 2020 at 04:35:16PM +0200, Étienne Mollier wrote: > > IMHO if upstream makes it very hard to be contacted our effort > > we should do should not be exagerated. > > I'm not entirely sure I understood your opinion, but if there > are more projects requiring a Google Account to contact > upstream, then I'll probably reconsider getting one. I intended to say that upstream should not require people to create any account if they are interested in feedback. > After all, there are so many projects on Github today, that I > ended up opening an account last month just to allow myself > interacting with upstream. It seems to have been a good move > given the positive reactions I received on that side so far. :) Github is quite an important development platform and our BTS is checking Github issues if the forward property is set accordingly. Here it makes more sense than subscribing a Google list which will spam you with noise. Kind regards Andreas. -- http://fam-tille.de
Re: RFS paml - fixed #957659
Hi Andreas, Andreas Tille, on 2020-05-09 18:44:40 +0200: > On Sat, May 09, 2020 at 04:35:16PM +0200, Étienne Mollier wrote: > > > IMHO if upstream makes it very hard to be contacted our effort > > > we should do should not be exagerated. > > > > I'm not entirely sure I understood your opinion, but if there > > are more projects requiring a Google Account to contact > > upstream, then I'll probably reconsider getting one. > > I intended to say that upstream should not require people to > create any account if they are interested in feedback. > > > After all, there are so many projects on Github today, that I > > ended up opening an account last month just to allow myself > > interacting with upstream. It seems to have been a good move > > given the positive reactions I received on that side so far. :) > > Github is quite an important development platform and our BTS is > checking Github issues if the forward property is set accordingly. Here > it makes more sense than subscribing a Google list which will spam you > with noise. Thank you for your clarification, and the warning about Google lists. It is unfortunate but sound ; and I guess if upstream wishes to not be contacted in conventional way, this should be respected as well. So it looks like the situation is fair enough as is I guess. Kind Regards, -- Étienne Mollier Fingerprint: 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d Help find cures against the Covid-19 ! Give CPU cycles: * Rosetta@home: https://boinc.bakerlab.org/rosetta/ * Folding@home: https://foldingathome.org/ signature.asc Description: PGP signature
Re: RFS paml - fixed #957659
On Fri, May 8, 2020 at 2:27 PM Étienne Mollier wrote: > Good day, > > > I have not forwarded the patch for the moment, since reporting > bugs requires posting in a Google Group that forbids contact > through email, and I have no Google account for the moment, at > least none usable to my knowledge. :( > Feel free to use me as a mail forwarder :-) -- Michael R. Crusoe
Re: RFS paml - fixed #957659
Hi Michael,
Michael Crusoe, on 2020-05-09 19:48:06 +0200:
> On Fri, May 8, 2020 at 2:27 PM Étienne Mollier
> wrote:
>
> > Good day,
> >
> >
> > I have not forwarded the patch for the moment, since reporting
> > bugs requires posting in a Google Group that forbids contact
> > through email, and I have no Google account for the moment, at
> > least none usable to my knowledge. :(
> >
>
> Feel free to use me as a mail forwarder :-)
Good point! That's one of the good things about being part of a
team of course! :)
Please, if you, or anyone else in the team having a Google
account, would be kind enough to forward the patch against
src/paml.h fixing #957659[0], available both here[1] and in
attachment, and which follows GNU recommendation toward using
"extern" statements for globals in use in multiple files when
moving to Gcc 10[2], to the Google Group related to the PAML
software[3], then that would be really nice. :)
[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=957659
[1]
https://salsa.debian.org/med-team/paml/-/blob/master/debian/patches/gcc10.patch
[2] https://gcc.gnu.org/gcc-10/porting_to.html
[3] https://groups.google.com/forum/#!forum/pamlsoftware
Kind Regards,
--
Étienne Mollier
Fingerprint: 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d
Help find cures against the Covid-19 ! Give CPU cycles:
* Rosetta@home: https://boinc.bakerlab.org/rosetta/
* Folding@home: https://foldingathome.org/
Description: fix ftbfs with gcc 10
Author: Étienne Mollier
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=957659
Forwarded: no
Last-Update: 2020-05-08
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- paml.orig/src/paml.h
+++ paml/src/paml.h
@@ -372,9 +372,9 @@
void printSptree(void);
-enum {BASEseq=0, CODONseq, AAseq, CODON2AAseq, BINARYseq, BASE5seq} SeqTypes;
+extern enum {BASEseq=0, CODONseq, AAseq, CODON2AAseq, BINARYseq, BASE5seq} SeqTypes;
-enum {PrBranch=1, PrNodeNum=2, PrLabel=4, PrNodeStr=8, PrAge=16, PrOmega=32} OutTreeOptions;
+extern enum {PrBranch=1, PrNodeNum=2, PrLabel=4, PrNodeStr=8, PrAge=16, PrOmega=32} OutTreeOptions;
/* use mean (0; default) for discrete gamma instead of median (1) */
signature.asc
Description: PGP signature
Re: RFS: cgview
Hi Pranav, On Sat, May 09, 2020 at 09:54:56PM +0530, Pranav Ballaney wrote: > I've added autopkgtests to cgview. Since the output is an image, I haven't > compared it to a reference - is that alright? Its definitely better than nothing. > If not, how do we usually test packages like this? I tried running a diff > but that reported the files to be different, even though they were visually > the same. I somehow thought there are some image comparison packages inside Debian. A short search has lead me to https://softwarerecs.stackexchange.com/questions/9774/command-line-tool-to-check-whether-two-images-are-exactly-the-same-graphically which recommends identify -quiet -format "%#" images... > Please take a look and let me know if any additional steps are required. > https://salsa.debian.org/med-team/cgview Please note that I used xz compression on the xml data to save some space also on developers machines. I've also called routine-update -f to update the packaging. I do not think that the image comparison is mandatory here - its way better to test at all than to make it perfect. But if you want to give identify a try that would be fine. However, we have a remaining problem in my pbuilder chroot: autopkgtest [19:32:42]: test run-unit-test: [--- run-detectors: unable to find an interpreter for /usr/bin/cgview autopkgtest [19:32:43]: test run-unit-test: ---] autopkgtest [19:32:43]: test run-unit-test: - - - - - - - - - - results - - - - - - - - - - run-unit-testFAIL non-zero exit status 2 It somehow sounds similar to this thread: https://lists.debian.org/debian-java/2016/04/msg00098.html I'd recommend to check with debian-j...@lists.debian.org . In the case of artfastqgenerator I've circumvented the problem a wrapper script. Hope this helps Andreas. -- http://fam-tille.de
Re: Idea wanted: What is the most key open source projects to fight COVID-19?
Hi Andreas, The 3 pipelines nf-core/nanoseq, nf-core/artic, nf-core/viralrecon I shared are the most applicable (= the highest priority) to COVID-19 analysis. [1]. Now I share the additional 5 pipelines that are certainly relevant (= the 2nd highest priority). [2] This is the result of my interview in the nf-core Slack channel. Could you check the packages situations in Debian? Sorry I knew information about the 5 pipelines a few weeks ago. But I took a time to summarize the list of the packages and email it. * nf-core/scrnaseq (single cell) * nf-core/smartseq2 (single cell) * nf-core/sarek (whole-genome sequencing) * nf-core/mag (meta-genomics) * nf-core/bcellmagic (immune response) https://github.com/nf-core/scrnaseq/blob/master/bin/scrape_software_versions.py bustools kallisto multiqc salmon star https://github.com/nf-core/smartseq2/blob/master/bin/scrape_software_versions.py fastqc multiqc https://github.com/nf-core/sarek/blob/master/bin/scrape_software_versions.py allelecount ascat bcftools bwa fastqc freebayes gatk htslib manta multiqc qualimap r samtools snpeff strelka tiddit vcftools vep https://github.com/nf-core/mag/blob/master/bin/scrape_software_versions.py busco cat centrifuge fastp fastqc filtlong kraken2 megahit metabat multiqc nanolyse nanoplot porechop quast spades https://github.com/nf-core/bcellmagic/blob/master/bin/scrape_software_versions.py changeo fastqc multiqc muscle presto r r-alakazam r-shazam r-tigger vsearch [1] nf-core Slack #covid19 channel https://nfcore.slack.com/archives/C0105J0J9T8/p1587480925053900 > The pipelines you listed are the ones that are/will be most applicable to COVID-19 analysis. [2] nf-core Slack #covid19 channel https://nfcore.slack.com/archives/C0105J0J9T8/p1587498948095200 > But the single cell pipelines could certainly be relevant. Also sarek for whole-genome sequencing analysis, mag for metagenomics analysis and bcellmagic for investigations into the immune response.. Thanks & Cheers, Jun -- Jun | He - His - Him
Re: RFS paml - fixed #957659
Hi, For once, maybe I can be of some help there. I shall be able to reach the author of PAML directly... shall I give it a try? Julien. On Sat, May 9, 2020 at 8:31 PM Étienne Mollier wrote: > Hi Michael, > > Michael Crusoe, on 2020-05-09 19:48:06 +0200: > > On Fri, May 8, 2020 at 2:27 PM Étienne Mollier < > etienne.moll...@mailoo.org> > > wrote: > > > > > Good day, > > > > > > > > > I have not forwarded the patch for the moment, since reporting > > > bugs requires posting in a Google Group that forbids contact > > > through email, and I have no Google account for the moment, at > > > least none usable to my knowledge. :( > > > > > > > Feel free to use me as a mail forwarder :-) > > Good point! That's one of the good things about being part of a > team of course! :) > > Please, if you, or anyone else in the team having a Google > account, would be kind enough to forward the patch against > src/paml.h fixing #957659[0], available both here[1] and in > attachment, and which follows GNU recommendation toward using > "extern" statements for globals in use in multiple files when > moving to Gcc 10[2], to the Google Group related to the PAML > software[3], then that would be really nice. :) > > [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=957659 > [1] > https://salsa.debian.org/med-team/paml/-/blob/master/debian/patches/gcc10.patch > [2] https://gcc.gnu.org/gcc-10/porting_to.html > [3] https://groups.google.com/forum/#!forum/pamlsoftware > > Kind Regards, > -- > Étienne Mollier > Fingerprint: 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d > Help find cures against the Covid-19 ! Give CPU cycles: > * Rosetta@home: https://boinc.bakerlab.org/rosetta/ > * Folding@home: https://foldingathome.org/ > -- Julien Y. Dutheil, Ph-D 0 (+49) 4522 763 298 § Max Planck Institute for Evolutionary Biology Molecular Systems Evolution Department of Evolutionary Genetics Plön -- GERMANY § Institute of Evolutionary Sciences - Montpellier University of Montpellier 2 -- FRANCE
RFS: gasic
Hi, I've added autopkgtests to gasic. Please review and sponsor. https://salsa.debian.org/med-team/gasic/ Regards, Pranav ᐧ
Re: RFS: cgview
Hi Andreas, On Sun, May 10, 2020 at 1:21 AM Andreas Tille wrote: > Hi Pranav, > > On Sat, May 09, 2020 at 09:54:56PM +0530, Pranav Ballaney wrote: > > I've added autopkgtests to cgview. Since the output is an image, I > haven't > > compared it to a reference - is that alright? > > Its definitely better than nothing. > > > If not, how do we usually test packages like this? I tried running a diff > > but that reported the files to be different, even though they were > visually > > the same. > > I somehow thought there are some image comparison packages inside Debian. > A short search has lead me to > > > https://softwarerecs.stackexchange.com/questions/9774/command-line-tool-to-check-whether-two-images-are-exactly-the-same-graphically > > which recommends > >identify -quiet -format "%#" images... > > > Please take a look and let me know if any additional steps are required. > > https://salsa.debian.org/med-team/cgview > > Please note that I used xz compression on the xml data to save some > space also on developers machines. I've also called routine-update -f > to update the packaging. I do not think that the image comparison is > mandatory here - its way better to test at all than to make it perfect. > But if you want to give identify a try that would be fine. > Okay then let's leave the test here. Thanks for the compression, I'll keep that in mind for future tests. However, we have a remaining problem in my pbuilder chroot: > > autopkgtest [19:32:42]: test run-unit-test: [--- > run-detectors: unable to find an interpreter for /usr/bin/cgview > autopkgtest [19:32:43]: test run-unit-test: ---] > autopkgtest [19:32:43]: test run-unit-test: - - - - - - - - - - results - > - - - - - - - - - > run-unit-testFAIL non-zero exit status 2 > > This is weird - all tests pass in my chroot. Could it be like the issue we had with loki a few months ago? It worked perfectly on Liubov's machine too. @Nilesh, could you please take a look here? > It somehow sounds similar to this thread: > > https://lists.debian.org/debian-java/2016/04/msg00098.html > > I'd recommend to check with debian-j...@lists.debian.org . In > the case of artfastqgenerator I've circumvented the problem > a wrapper script. Let's let Nilesh try it once, and if the problem persists, we'll take it up with the Java team. Regards, Pranav ᐧ
Re: RFS: cgview
On Sun, 10 May 2020 at 03:17, Pranav Ballaney wrote: > Hi Andreas, > > On Sun, May 10, 2020 at 1:21 AM Andreas Tille wrote: > >> Hi Pranav, >> >> On Sat, May 09, 2020 at 09:54:56PM +0530, Pranav Ballaney wrote: >> > I've added autopkgtests to cgview. Since the output is an image, I >> haven't >> > compared it to a reference - is that alright? >> >> Its definitely better than nothing. >> >> > If not, how do we usually test packages like this? I tried running a >> diff >> > but that reported the files to be different, even though they were >> visually >> > the same. >> >> I somehow thought there are some image comparison packages inside Debian. >> A short search has lead me to >> >> >> https://softwarerecs.stackexchange.com/questions/9774/command-line-tool-to-check-whether-two-images-are-exactly-the-same-graphically >> >> which recommends >> >>identify -quiet -format "%#" images... >> >> > Please take a look and let me know if any additional steps are required. >> > https://salsa.debian.org/med-team/cgview >> >> Please note that I used xz compression on the xml data to save some >> space also on developers machines. I've also called routine-update -f >> to update the packaging. I do not think that the image comparison is >> mandatory here - its way better to test at all than to make it perfect. >> But if you want to give identify a try that would be fine. >> > > Okay then let's leave the test here. Thanks for the compression, I'll keep > that in mind for future tests. > > However, we have a remaining problem in my pbuilder chroot: >> >> autopkgtest [19:32:42]: test run-unit-test: [--- >> run-detectors: unable to find an interpreter for /usr/bin/cgview >> autopkgtest [19:32:43]: test run-unit-test: ---] >> autopkgtest [19:32:43]: test run-unit-test: - - - - - - - - - - results >> - - - - - - - - - - >> run-unit-testFAIL non-zero exit status 2 >> >> > This is weird - all tests pass in my chroot. Could it be like the issue we > had with loki a few months ago? > It worked perfectly on Liubov's machine too. > > @Nilesh, could you please take a look here? > > >> It somehow sounds similar to this thread: >> >> https://lists.debian.org/debian-java/2016/04/msg00098.html >> >> I'd recommend to check with debian-j...@lists.debian.org . In >> the case of artfastqgenerator I've circumvented the problem >> a wrapper script. > > > Let's let Nilesh try it once, and if the problem persists, we'll take it > up with the Java team. > It doesn't work for me. However the error is different from Andreas's. Pasting them below: (Reading database ... 17925 files and directories currently installed.) Removing autopkgtest-satdep (0) ... autopkgtest [03:50:57]: test run-unit-test: [--- /tmp/autopkgtest.VDRUQo/build.fD2/real-tree/debian/tests/run-unit-test: line 22: /usr/bin/cgview: cannot execute binary file: Exec format error autopkgtest [03:50:58]: test run-unit-test: ---] autopkgtest [03:50:58]: test run-unit-test: - - - - - - - - - - results - - - - - - - - - - run-unit-testFAIL non-zero exit status 126 autopkgtest [03:50:58]: summary run-unit-testFAIL non-zero exit status 126 Liubov, could you try this once and let us know the output? Kind Regards, Nilesh
Re: RFS: cgview
On Sun, May 10, 2020 at 03:57:50AM +0530, Nilesh Patra wrote: > >> > >> autopkgtest [19:32:42]: test run-unit-test: [--- > >> run-detectors: unable to find an interpreter for /usr/bin/cgview > >> autopkgtest [19:32:43]: test run-unit-test: ---] > >> autopkgtest [19:32:43]: test run-unit-test: - - - - - - - - - - results > >> - - - - - - - - - - > >> run-unit-testFAIL non-zero exit status 2 > >> > >> It somehow sounds similar to this thread: > >> > >> https://lists.debian.org/debian-java/2016/04/msg00098.html > >> > >> I'd recommend to check with debian-j...@lists.debian.org . In > >> the case of artfastqgenerator I've circumvented the problem > >> a wrapper script. > > It doesn't work for me. However the error is different from Andreas's. > Pasting them below: > > (Reading database ... 17925 files and directories currently installed.) > Removing autopkgtest-satdep (0) ... > autopkgtest [03:50:57]: test run-unit-test: [--- > /tmp/autopkgtest.VDRUQo/build.fD2/real-tree/debian/tests/run-unit-test: > line 22: /usr/bin/cgview: cannot execute binary file: Exec format error > autopkgtest [03:50:58]: test run-unit-test: ---] > autopkgtest [03:50:58]: test run-unit-test: - - - - - - - - - - results - > - - - - - - - - - > run-unit-testFAIL non-zero exit status 126 > autopkgtest [03:50:58]: summary > run-unit-testFAIL non-zero exit status 126 This even more sounds like https://lists.debian.org/debian-java/2016/04/msg00098.html Kind regards Andreas. -- http://fam-tille.de
Re: RFS paml - fixed #957659
On Sat, May 09, 2020 at 10:32:32PM +0200, Julien Yann Dutheil wrote: > For once, maybe I can be of some help there. I shall be able to reach the > author of PAML directly... shall I give it a try? Yes, please forward the patch - basically in the interest of the PAML authors themselves. Kind regards Andreas. -- http://fam-tille.de
Re: RFS: gasic
Hi Pranav, On Sun, May 10, 2020 at 02:58:32AM +0530, Pranav Ballaney wrote: > I've added autopkgtests to gasic. Please review and sponsor. > https://salsa.debian.org/med-team/gasic/ thank you for adding this test. There is one cosmetic issue and a problematic issue. The cosmetic thing is that the additional data are blowing up this quite small package a lot. I do not think that we should bloat user machines too much. Thus it would be better to ship the data in an extra binary package gasic-examples. But here comes the harder part: I get autopkgtest [05:12:46]: test run-unit-test: [--- /tmp/autopkgtest.qJbg1v/tree/debian/tests/run-unit-test: line 23: 903 Segmentation fault bowtie-build dwv.fasta dwv.fasta autopkgtest [05:12:47]: test run-unit-test: ---] in my pbuilder chroot. I remember I once had a similar issue with bowtie before. Its a bit hard to seek in BTS and I have no idea whether it makes sense to seek at all. But it would be great if you could reproduce this somehow and we could debug that issue - which is probably an issue in bowtie - it just should not segfault. Kind regards Andreas. -- http://fam-tille.de
