autopkgtest fail due to broken PNG images in openscad-testing-data
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
openscad (Ubuntu) |
Fix Released
|
Medium
|
Christian Ehrhardt |
Bug Description
openscad/2021.01-1 never worked.
Bad on First Februaray and up to now.
1072 - pdfexporttest_
All good tests are wit the old version 2019.05-5
This package is entangled with libzip which blocks quite a bunch of others.
So unblocking this would help proposed more than just for this package.
Works fine in Debian Ci:
https:/
Checked a local VM based repro as-is and all-proposed.
Both failed.
We have two files that are compared:
-rw-rw-r-- 1 ubuntu ubuntu 29568 Mar 10 12:20 /tmp/autopkgtes
-rw-rw-r-- 1 ubuntu ubuntu 29502 Jan 31 21:17 /tmp/autopkgtes
Unfortunately the test fail is on comparison
Image comparison cmdline: /usr/bin/convert regression/
actual image: /tmp/autopkgtes
expected image: regression/
Image comparison return: 0 output: convert: iCCP: profile 'default_gray.icc': 'GRAY': Gray color space not permitted on RGB PNG `regression/
8
Traceback (most recent call last):
File "/tmp/autopkgte
if not verification or not compare_
File "/tmp/autopkgte
if "compare_" + options.suffix in globals(): return globals(
File "/tmp/autopkgte
pixelerr = int(float(
ValueError: could not convert string to float: "convert: iCCP: profile 'default_gray.icc': 'GRAY': Gray color space not permitted on RGB PNG `regression/
<end of output>
Test time = 5.00 sec
-------
Test Failed.
But executing said comparison myself in the very same test env works fine:
ubuntu@
ubuntu@
0
Involved versions of imagemagick
Debian: 8:6.9.11.60+dfsg-1
Ubuntu: 8:6.9.10.
Running the full testsuite recreates the issue.
The isolated way to trigger this is via:
# enter the test dir that was created
cd /tmp/autopkgtes
# run the full set
"/usr/bin/python3" "./test_
Detail per stage:
Works: /usr/bin/python3 ./export_pngtest.py ./../testdata/
Fails: /usr/bin/convert regression/
We can copy out the files and run it on those dirctly:
ubuntu@
Also complains in Focal for: 8:6.9.10.
Copying these files into a Debian with 8:6.9.11.58+dfsg-1 is broken as well
Upgrading imagemagick-6.q16 in Debian to 8:6.9.11.60+dfsg-1 breaks as well.
Hmm, so it isn't just the imagemagick version.
Maybe the result of the PDF conversion really is different.
Getting those files from Debian ... and comparing them.
The test run there works fine.
The created files are different, but not only "actual" also the expected file is.
I was reading detailed attributes from these png's via
identify -verbose ubuntu.
identify -verbose debian.
identify -verbose ubuntu.
identify -verbose debian.
And it turns out what is broken is the ubuntu.
Also it has a vastly different file size:
$ ll ubuntu.
-rw-r--r-- 1 paelzer paelzer 29568 Mär 10 14:41 debian.
-rw-r--r-- 1 paelzer paelzer 29502 Mär 10 14:41 debian.
-rw-rw-r-- 1 paelzer paelzer 29568 Mär 10 14:26 ubuntu.
-rw-r--r-- 1 paelzer paelzer 18446 Mär 10 14:26 ubuntu.
Even the check of debian.expected vs ubuntu-actial is valid
$ /usr/bin/convert debian.
So why is "out" expected file broken and how is it created.
The expected file in Ubuntu has "Colorspace: sRGB" while all others
have "Colorspace: Gray". Also the properties are very different:
- icc:copyright: Copyright Artifex Software 2018
- icc:description: Artifex Software sGray ICC Profile
- png:iCCP: chunk was found
- png:IHDR.
- png:IHDR.bit_depth: 8
- png:IHDR.
- png:IHDR.
+ date:create: 2021-03-
+ date:modify: 2021-03-
+ png:IHDR.
+ png:IHDR.bit_depth: 2
+ png:IHDR.
+ png:IHDR.
The file in the package source itself is equal.
f43804573fceeb8
f43804573fceeb8
But for the test oen is in
(That still is the same)
f43804573fceeb8
The bad one is
dc6148ec8d80e47
That was created at build time of 2021.01-1build1
The older version of openscad-
Both 2021.01-1 builds have that bad file
https:/
https:/
This is installed by:
openscad-
testdata /usr/share/
tests/regression /usr/share/
But then in the source tests/regressio
When did it get corrupted?
A local sbuild rebuild of openscad recreated the issue.
But interestingly only in the file it installed.
See the size difference:
find -name centered-
-rw-r--r-- 1 paelzer paelzer 18446 Jan 31 20:17 ./openscad-
-rw-r--r-- 1 paelzer paelzer 29502 Jan 31 20:17 ./openscad-
Hmm:
pkgstripfiles: Running PNG optimization (using 3 cpus) for package openscad-
Maybe that killed my file content?
$ rm -rf debian/
$ mkdir -p debian/
$ f="debian/
$ cp -a ./tests/
$ cp -a ./tests/
$ optipng -o4 -preserve "$f"
** Processing: debian/
2479x3508 pixels, 8 bits/pixel, grayscale
Reducing image to 2 bits/pixel, 4 colors in palette
Input IDAT size = 27039 bytes
Input file size = 29502 bytes
Trying:
zc = 9 zm = 8 zs = 0 f = 0 IDAT size = 16026
zc = 9 zm = 8 zs = 1 f = 0 IDAT size = 15995
Selecting parameters:
zc = 9 zm = 8 zs = 1 f = 0 IDAT size = 15995
Output IDAT size = 15995 bytes (11044 bytes decrease)
Output file size = 18446 bytes (11056 bytes = 37.48% decrease)
$ advpng -q -z4 "$f"
I double checked, optipng would break it in Debian as well.
Why it didn't in the past is a riddle to me, are our policies differently?
Turns out this isn't as much of a riddle as I thought:
[15:46] <cpaelzer> so I wonder why this runs for us but not in the Debian build, but since this is an area I never touched I wanted to ask for some experience or guidance where to look at
[15:48] <cjwatson> cpaelzer: pkgstripfiles existing at all is different between Debian/Ubuntu
Now that this is clear the fix is easy via $NO_PNG_PKG_MANGLE
Build log with the fix, showing the now intact files