Re: Fitspng autopkgtest regression fail, Bug #1059970
Dear Paul,
thank you for your feedback. I did some detailed investigation
recently, as the response on your recommendation, and found that
the trouble is not related on fitspng itself. Actually, it is
caused by pngcheck, a testing tool due libpng. The fitspng test
script just consider it as an independent verifier.
Technical details are left below. The warning is due current
binary of pngcheck compiled against an old zlib. The binary
has been not recompiled with the current version of zlib yet.
I propose the solution: I will contact the building team
via wanna-build actions to request recompile, and to inform
the package maintainer of course.
Thank you very much,
FH
-- Details
A test under sid (as well as trixie) has revealed the warning:
x@trixiesid:/tmp/xxx$ pngcheck hippo.png
zlib warning: different version (expected 1.2.13, using 1.3)
OK: hippo.png (139x152, 24-bit RGB, non-interlaced, 38.7%).
The string can be identified as the part of the source of pngcheck.c [1]
which compares version of the run-time zlib and the zlib compiled in:
...
} else if (strcmp(zlib_version, ZLIB_VERSION) != 0) {
fprintf(stderr, "zlib warning: different version (expected %s,"
" using %s)\n\n", ZLIB_VERSION, zlib_version);
}
..
In my opinion, the test on a zlib version is greatly valuable.
--
[1]
https://salsa.debian.org/debian/pngcheck/-/blob/debian/master/pngcheck.c?ref_type=heads
On Wed, 2024-01-17 at 21:06 +0100, Paul Gevers wrote:
> Hi Filip,
>
> On 17-01-2024 15:21, Filip Hroch wrote:
> > I'm asking for help with solving of Bug #1059970 (see [1])
> > with the issue:
> >
> > check FAIL stderr: zlib warning: different version (expected
> > 1.2.13, using 1.3)
> >
> > One is, in my opinion, caused by indirect linking of the zlib
> > by libcfitsio-dev and libpng-dev; libcfitsio-dev is linked
> > against zlib1g (>= 1:1.1.4), whilst libpng-dev against
> > zlib1g (= 1:1.3.dfsg-3).
> >
> > Is there a a way how to solve this kind of troubles?
>
> There are multiple angles to your question: which troubles do you want
> to solve? In my opinion, in Debian the best solution is to remove the
> warning if it's harmless that the version mismatch (which probably
> should just be removed upstream too). You *should* have tests in place
> now that tell you that the package is working as intended, "proving"
> it's harmless. If, for some reason, there are serious issues with the
> version skew that are *not* caught by your test, than the warning isn't
> going to help the user of Debian packages much either way. If there
> should really be a version lock, than your package should declare that
> in its relations (versioned Depends), such that the Release Teams tools
> pick it up an a rebuild can be scheduled. But I really think this last
> option is probably the wrong solution.
>
> If you just want to prevent the test from failing on a warning, you can
> use the allow-stderr restriction.
>
> Paul
>
> > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059970
--
F. Hroch <hroch@physics.muni.cz>, Masaryk University,
Dept. of theor. physics and astrophysics, Brno, Moravia, CZ
Reply to: