[Debian-med-packaging] Bug#833004: Do you have resources to look after ball? [progress info]

[Andreas Tille]

Hi Danny

On Sat, Nov 12, 2016 at 11:52:47AM +0100, Danny Edel wrote:
> On 11/11/2016 02:29 PM, Andreas Tille wrote:
> >         Start 197: AmberFF_test
> > 197/334 Test #197: AmberFF_test .................................***Failed    0.19 sec
> > (...)
> >     (line 511 TEST_REAL_EQUAL(r4_r1 - r4_i, r1_r4 - r1_i): got -145.471, expected -103.957)  - 
> >     (line 513 TEST_REAL_EQUAL(r1_r4 - r1_i + r1_tpl + r4_tpl + tpl_i, total_energy): got 1680.36, expected 1638.84)  - 
> >     FAILED
> > FAILED
> 
> > Considering Steffen's answer it might be worth trying the said
> > snapshot if this might be fixed there.
> 
> this looks like upstream bug [584][], and appears to be intermittent,
> but from what I can tell, no code has been added to address this in
> upstream master.  So upgrading to a snapshot would not necessarily help.
> 
> However, I can *not* reproduce the AmberFF_test failure.  Neither in my
> Debian testing environment, nor in an unstable chroot freshly created
> with git-pbuilder.
> 
> I literally ran the AmberFF_test one thousand times and it did not fail
> once.  Of course, that doesn't mean it won't fail on the 1001st time,
> but I have no idea how to effectively approach this without deep
> knowledge of the program and its algorithms.
> 
> Since we're talking floating-point arithmetic, and the results are not
> completely off (same sign, and at least within the same order of
> magnitude), this may be a hardware-specific corner-case resulting in
> greatly reduced precision.  For reference, I'm running on an Intel Core2
> 6600.
> 
> Trying the same code again and expecting a different result might not be
> very professional (or even sane), but we could upload to a buildd
> (experimental?) and see if the failure is reproducible there.

On my laptop I also can build the package.
 
> Of course, it is always an option to exclude this test to restore
> buildability.

I'd prefer to skip this test anyway (or let the test suite pass even
if it fails.

> The quality would certainly not be worse than before,
> when the testsuite was skipped entirely.
> 
> [584]: https://github.com/BALL-Project/ball/issues/584
> 
> Bottom line:  As much as I'd like to help out; without access to a box
> where the problem is reproducible, I am not able to.

Sure.  If you confirm you would volunteer to exclude the test I'll
delay the upload.  I'd also fix some lintian issues before uploading.

Thanks again for your very welcome help

      Andreas.

-- 
http://fam-tille.de