[Debian-med-packaging] We are basically through libbpp* upgrade

[Julien Yann Dutheil]

Dear Andreas,

I have committed a patch for libbpp-phyl, I hope it will solve the failing
test on the remaining architectures.
I have also made an update for maffilter. Some notes regarding that one:
- There are 3 lintian warnings about linked but unused libraries. One
(boost regex) is included automatically by the inclusion of boost-iostream
in cmake, I do not know how to get rid of it. The two others (gzip and
bzip) are required for the program to link properly. I I do not include
them it fails (and I actually need them, I do not use them directly but via
some wrappers in boost-iostream).
- I have read that BUILD_TYPE should be set to "None" when building a cmake
project. If I do so, however, I get a warning about missing debug symbols.
For me it only works if I set BUILD_TYPE=RelWithDebInfos (applies to
maffilter, bppsuite, bppphyview and physamp). If there is a better solution
I'd be happy to implement it.

Best,

Julien.

On Wed, Apr 18, 2018 at 9:41 PM, Andreas Tille <tille at debian.org> wrote:

> Hi Julien,
>
> On Wed, Apr 18, 2018 at 09:20:29PM +0200, Julien Yann Dutheil wrote:
> > Thanks for all the efforts!
>
> You are welcome.
>
> > I have now prepared the release for bppphyview and physamp
>
> Uploaded.
>
> > (so only maffilter left...).
>
> Waiting for your commits. :-)
>
> > As for the bpp-phyl test failure, this looks like numerical precision
> > issues, again. Maybe you have some hints there: what this test does is
> > essentially to minimize a rather complex function, and makes sure that it
> > always find the same result. The problem is that this "result" varies
> from
> > one platform to another, because of numerical precision issues. I guess
> > this suggests that such tests are not very well designed, as they are not
> > robust to different platforms. Yet they are useful in the sense that they
> > do allow us to check that we did not break anything, at least on our
> > machines. What would you suggest in such case? Shall we just remove these
> > tests? I'm well aware this goes a bit beyond pure packaging issues, sorry
> > about that :s
>
> I have not thoroughly inspected the logs but from what you write it
> smells somehow like relaxing precision the test results that are
> compared (= increasing the boundary that is considered a valid result).
> If all else fails you could consider making the limit depend from a
> variable that contains the architecture.
>
> If you might hesitate to refine the tests in this direction it might
> be an option to kick that test for the failing architectures.  Something
> in debian/rules we used to kick the symbols file for most architectures
> could call patch / sed / whatever for the failing architectures and
> deactivate the test only there.
>
> Does these ideas help or do you need more precise advise?
>
> Kind regards
>
>      Andreas.
>
> --
> http://fam-tille.de
>



-- 
Julien Y. Dutheil, Ph-D
0 (+49) 6421 178 986

§ 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/debian-med-packaging/attachments/20180430/9b5583df/attachment-0001.html>