Hello,
On 27.9.2017 19:49, Ondřej Surý wrote:
Hi,
I think this is reasonable, but I would really appreciate patches for
autopkgtest.
I have uploaded some proposed changes on github:
https://github.com/jpalecek/libgd2-debian. They disable the testing
during build and create autopkgtest consisting primarily of the same
tests. Although there are some examples using the actual build (like
http://bazaar.launchpad.net/~ubuntu-clock-dev/ubuntu-clock-app/trunk/revision/50)
for test, I made sure the test uses the installed library package
instead. However, there are still open issues:
1. The source tree contains automake and cmake build system, but you
seem to only be using automake. Therefore I just considered automake
(and eg. didn't bother to run ctest)
2. Although the autopkgtests shouldn't use built libraries from the
source tree, they still write to it (and build it). When you run
autopkgtest with a chroot or qemu virtualization, this isn't much of an
issue, but isn't very clean still.
3. The change to use installed libgd instead of built one
(https://github.com/jpalecek/libgd2-debian/commit/378139db3a114604edb580e21af8cb2cb1aef03e)
is an ugly hack (yet it still builds correctly on a clean system). If
the change to LDADD is too iffy it can only be applied to the tree when
testing.
4. Valgrind reports some uninitialized reads in other libraries. I
haven't looked into them, but I think it would be wise to just produce a
suppressions file and silence them.
Some of the other changes were necessary just to build the package. I
removed the -fno-omit-frame-pointer because it seemed odd, but if there
were eg. problems getting backtraces it can be returned.
Anyway, tell me what you think, maybe on github if convenient.
Regards
Jiri Palecek
Cheers,
Ondrej
On Mon, 25 Sep 2017 at 04:51 Jiri Palecek <jpale...@web.de
<mailto:jpale...@web.de>> wrote:
Hello,
I was looking at the recent FTBFS of libgd2, which prevented security
fixes to reach debian archive for more than a week. The FTBFS were
restricted to several architectures.
By the look of it, it seems that the errors are simple arithmetical
inaccuracies, when the tests expect pixel-exact results. I was
specifically concerned about gdimagerotate/bug00067 test on i386, and
the result of the rotate operation, while not comparing equal to the
expected image, seemed the same to the naked eye.
Slight differences of the computations on different architectures
are to
be expected, eg. if those architectures use different floating point
formats, although it shouldn't matter that much in the test I
mentioned
(by rough estimate it should need a precision of about 1/2^18 --
1/2^20,
while IEE754 float is more precise than that). However, I was
surprised
that when I tested it with optimizations turned off, there were
failures
in the test suite too, but _different_ failures. This should mean
there's something dodgy going on either in gcc or in the code.
Anyway, I guess libgd2's aim isn't to provide pixel perfect image
manipulations, but rather accessible image functions for eg. web
servers
in PHP. In that case, the testsuite doesn't really reflect the
requirements it should fulfill, and it should focus more on security
than accuracy.
I would propose to ditch the testsuite completely from the building
process of the package, since in its present state, it is inherently
unreliable and would cause FTBFS. Instead, an autopkgtest testsuite
could be made (with the running the same tests), which could be
automatically ran using ci.debian.org <http://ci.debian.org>. Such
a testsuite could probably
even be rigged to run under valgrind, which could catch some memory
errors. At the same time, the testsuite could be made more lenient (or
the library code more accurate), but that would require substantially
more work and I don't know whether it would be desirable.
Please let me know what you think.
Regards
Jiri Palecek
--
pkg-GD-devel mailing list
pkg-gd-de...@lists.alioth.debian.org
<mailto:pkg-gd-de...@lists.alioth.debian.org>
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-gd-devel
--
Ondřej Surý <ond...@sury.org <mailto:ond...@sury.org>>
