<div dir="ltr">Dear Andreas,<div><br></div><div>I have committed a patch for libbpp-phyl, I hope it will solve the failing test on the remaining architectures.</div><div>I have also made an update for maffilter. Some notes regarding that one:</div><div>- 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). </div><div>- 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.</div><div><br></div><div>Best,</div><div><br></div><div>Julien.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 18, 2018 at 9:41 PM, Andreas Tille <span dir="ltr"><<a href="mailto:tille@debian.org" target="_blank">tille@debian.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Julien,<br>
<span class=""><br>
On Wed, Apr 18, 2018 at 09:20:29PM +0200, Julien Yann Dutheil wrote:<br>
> Thanks for all the efforts!<br>
<br>
</span>You are welcome.<br>
<span class=""><br>
> I have now prepared the release for bppphyview and physamp<br>
<br>
</span>Uploaded.<br>
<br>
> (so only maffilter left...).<br>
<br>
Waiting for your commits. :-)<br>
<span class=""><br>
> As for the bpp-phyl test failure, this looks like numerical precision<br>
> issues, again. Maybe you have some hints there: what this test does is<br>
> essentially to minimize a rather complex function, and makes sure that it<br>
> always find the same result. The problem is that this "result" varies from<br>
> one platform to another, because of numerical precision issues. I guess<br>
> this suggests that such tests are not very well designed, as they are not<br>
> robust to different platforms. Yet they are useful in the sense that they<br>
> do allow us to check that we did not break anything, at least on our<br>
> machines. What would you suggest in such case? Shall we just remove these<br>
> tests? I'm well aware this goes a bit beyond pure packaging issues, sorry<br>
> about that :s<br>
<br>
</span>I have not thoroughly inspected the logs but from what you write it<br>
smells somehow like relaxing precision the test results that are<br>
compared (= increasing the boundary that is considered a valid result).<br>
If all else fails you could consider making the limit depend from a<br>
variable that contains the architecture.<br>
<br>
If you might hesitate to refine the tests in this direction it might<br>
be an option to kick that test for the failing architectures.  Something<br>
in debian/rules we used to kick the symbols file for most architectures<br>
could call patch / sed / whatever for the failing architectures and<br>
deactivate the test only there.<br>
<br>
Does these ideas help or do you need more precise advise?<br>
<br>
Kind regards<br>
<span class="HOEnZb"><font color="#888888"><br>
     Andreas.<br>
<br>
-- <br>
<a href="http://fam-tille.de" rel="noreferrer" target="_blank">http://fam-tille.de</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">Julien Y. Dutheil, Ph-D<br>0 (+49) 6421 178 986<div><br>§ Max Planck Institute for Evolutionary Biology<div>Molecular Systems Evolution</div><div>Department of Evolutionary Genetics</div><div>Plön -- GERMANY<br></div><br>§ Institute of Evolutionary Sciences - Montpellier<br>University of Montpellier 2 -- FRANCE</div></div></div></div></div>
</div>