Re: Lets maintain libbpp-phyl-omics in Debian Med team
Hi Julien,
some of the libbpp packages now arrived in unstable. It would be great
if you could try to reprocude the failures in the test cases. It might
be sensible to rebuild libbpp-seq in a clean Debian unstable chroot.
The build shows:
# For the moment ignore:
# 3/7 Test #3: test_io ..........................***Exception: Other 0.01 sec
# terminate called after throwing an instance of 'bpp::IOException'
# what(): Fasta::appendFromStream: can't read from istream input
#
# 86% tests passed, 1 tests failed out of 7
I'll push the missing libbpp packages to new meanwhile.
Kind regards
Andreas.
On Mon, Apr 11, 2016 at 01:09:55PM +0200, Andreas Tille wrote:
> Hi Julien,
>
> On Mon, Apr 11, 2016 at 12:19:29PM +0200, Julien Yann Dutheil wrote:
> > > On Mon, Apr 11, 2016 at 09:10:00AM +0200, Julien Yann Dutheil wrote:
> > > > I will look at the bug (and try to compile with gcc6 for a check of all
> > > > libs. As for bpp-seq, I think it is because it needs some input files
> > > that
> > > > should be in the test folder too (eg example.fasta, example.aln and
> > > > example.ph).
> > >
> > > I have verified that these files are existing in the very same folder as
> > > the test code. I'm not sure whether this is the correct location for
> > > these files since may be the test code will be started from a different
> > > folder (I tried a patch adding "test/" in front of the file names but
> > > this did not helped. I also tried deactivating single tests inside
> > > test_io - also with no success.
> > >
> >
> > They should be in the same directory as the program is launched (which is
> > "test/" in my CMake script).
>
> OK, so it might be worth investigating why it might fail. Are you able
> to reproduce this issue?
>
> > My plan is ultimately to deactivate unit
> > testing by default as several users have complained about that, but in the
> > mean time this can be done by adding BUILD_TESTING=OFF to the cmake command
> > line.
>
> I would consider switching of the tests a way backward. Debian is
> striving to get as most as possible package delivered with build time
> tests as well as test of the packages on the Debian mirror in regular
> intervals. Specifically for scientific software I'd regard this of high
> relevance and thus the Debian Med team is running a Google Summer of
> Code project to add more tests.
>
> I think the best way to cope with non passing tests is to give more
> detailed output on failing tests to let users check what might be
> wrong and make the tests more robust.
>
> There is no need to switch of the tests in general in the packaging as
> you can see in the according debian/rules file[1] I have worked around
> the issue and have provided an according documentation[2]. Hiding eyes
> from non-passing tests should not be the solution here.
>
> Kind regards
>
> Andreas.
>
>
> [1] https://anonscm.debian.org/cgit/debian-med/libbpp-seq.git/tree/debian/rules
> [2] https://anonscm.debian.org/cgit/debian-med/libbpp-seq.git/tree/debian/README.source
>
> --
> http://fam-tille.de
>
>
--
http://fam-tille.de
Reply to: