<div dir="ltr">Hi,<div><br></div><div>I think this is reasonable, but I would really appreciate patches for autopkgtest.</div><div><br></div><div>Cheers,</div><div>Ondrej</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, 25 Sep 2017 at 04:51 Jiri Palecek <<a href="mailto:jpalecek@web.de">jpalecek@web.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
I was looking at the recent FTBFS of libgd2, which prevented security<br>
fixes to reach debian archive for more than a week. The FTBFS were<br>
restricted to several architectures.<br>
<br>
By the look of it, it seems that the errors are simple arithmetical<br>
inaccuracies, when the tests expect pixel-exact results. I was<br>
specifically concerned about gdimagerotate/bug00067 test on i386, and<br>
the result of the rotate operation, while not comparing equal to the<br>
expected image, seemed the same to the naked eye.<br>
<br>
Slight differences of the computations on different architectures are to<br>
be expected, eg. if those architectures use different floating point<br>
formats, although it shouldn't matter that much in the test I mentioned<br>
(by rough estimate it should need a precision of about 1/2^18 -- 1/2^20,<br>
while IEE754 float is more precise than that). However, I was surprised<br>
that when I tested it with optimizations turned off, there were failures<br>
in the test suite too, but _different_ failures. This should mean<br>
there's something dodgy going on either in gcc or in the code.<br>
<br>
Anyway, I guess libgd2's aim isn't to provide pixel perfect image<br>
manipulations, but rather accessible image functions for eg. web servers<br>
in PHP. In that case, the testsuite doesn't really reflect the<br>
requirements it should fulfill, and it should focus more on security<br>
than accuracy.<br>
<br>
I would propose to ditch the testsuite completely from the building<br>
process of the package, since in its present state, it is inherently<br>
unreliable and would cause FTBFS. Instead, an autopkgtest testsuite<br>
could be made (with the running the same tests), which could be<br>
automatically ran using <a href="http://ci.debian.org" rel="noreferrer" target="_blank">ci.debian.org</a>. Such a testsuite could probably<br>
even be rigged to run under valgrind, which could catch some memory<br>
errors. At the same time, the testsuite could be made more lenient (or<br>
the library code more accurate), but that would require substantially<br>
more work and I don't know whether it would be desirable.<br>
<br>
Please let me know what you think.<br>
<br>
Regards<br>
<br>
     Jiri Palecek<br>
<br>
--<br>
pkg-GD-devel mailing list<br>
<a href="mailto:pkg-GD-devel@lists.alioth.debian.org" target="_blank">pkg-GD-devel@lists.alioth.debian.org</a><br>
<a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-gd-devel" rel="noreferrer" target="_blank">http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-gd-devel</a></blockquote></div><div dir="ltr">-- <br></div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Ondřej Surý <<a href="mailto:ondrej@sury.org">ondrej@sury.org</a>></div></div></div>