| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 28 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 55:44:53 |
| Calls: | 422 |
| Files: | 1,025 |
| Messages: | 90,711 |
Jochen Sprickerhof <jspricke@debian.org> hat am 16.05.2025 13:31 CEST geschrieben:
Hi,
* Paul Gevers <elbrus@debian.org> [2025-05-10 14:24]:
With a recent upload of imagemagick the autopkgtest of xplanet fails
in testing when that autopkgtest is run with the binary packages of >imagemagick from unstable. It passes when run with only packages from >testing. In tabular form:
pass fail
imagemagick from testing 8:7.1.1.47+dfsg1-1
xplanet from testing 1.3.1-3
all others from testing from testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of imagemagick to >testing [1]. Due to the nature of this issue, I filed this bug report >against both packages. Can you please investigate the situation and >reassign the bug to the right package?
There are multiple problems:
1. imagemagick changed the output of compare in 7.1.1-44 (d85a7583f)
from some number <= 1 with 1 meaning the images are the same two two
numbers where the first is the distortion and the second one is the
old percentage in parenthesis. This breaks the test code in
https://sources.debian.org/src/xplanet/1.3.1-3/debian/tests/compare-create-image/#L32
I assume that the new format will be kept so xplanet should adopt the
logic. Maybe something like:
result_jpg="$( compare -metric ncc $AUTOPKGTEST_TMP/expected/$filename.jpeg $AUTOPKGTEST_TMP/$filename.jpeg $AUTOPKGTEST_TMP/diff.jpg 2>&1 | sed 's/.*(\(.*\))/\1/' )"
2. imagemagick in stable returns values below 0 for similar but
different images. I did not check if this was different in older
versions but I would expect so, given that the autopkgtest code
checks the value for >0.99. This has been corrected by multiple
patches in imagemagick git main.
3. imagemagick in unstable has a bug resulting in the same picture
getting a percentage of 0 and different images a value of > 1. This
has also been corrected in imagemagick git main (912b6a838).
4. The results of earth_markers.* in the compare-create-image
autopkgtest improved (not sure due to what) so the files in
debian/tests/expected/earth_markers.* need to be replaced.
I think we have to accept that the output of compare is not stable and
adopt xplanet. I see two options what to do:
a. Adopt the xplanet to cope with any output of compare. This could be
either by just using the return value, hoping that the output on
different architectures is stable nowadays (I did not test this) or
by adding logic that only compares the number in case the return
value is not 0 (perfect match) and then try to interpret the
number(s).
b. Apply the imagemagick patches from git main and use the call from 1.
above.
Cheers Jochen
With a recent upload of imagemagick the autopkgtest of xplanet fails
in testing when that autopkgtest is run with the binary packages of >imagemagick from unstable. It passes when run with only packages from >testing. In tabular form:
pass fail
imagemagick from testing 8:7.1.1.47+dfsg1-1
xplanet from testing 1.3.1-3
all others from testing from testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of imagemagick to >testing [1]. Due to the nature of this issue, I filed this bug report >against both packages. Can you please investigate the situation and
reassign the bug to the right package?
Hi,
* Paul Gevers <elbrus@debian.org> [2025-05-10 14:24]:
With a recent upload of imagemagick the autopkgtest of xplanet fails
in testing when that autopkgtest is run with the binary packages of >imagemagick from unstable. It passes when run with only packages from
testing. In tabular form:
pass fail
imagemagick from testing 8:7.1.1.47+dfsg1-1
xplanet from testing 1.3.1-3
all others from testing from testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of imagemagick to >testing [1]. Due to the nature of this issue, I filed this bug report >against both packages. Can you please investigate the situation and >reassign the bug to the right package?
There are multiple problems:
1. imagemagick changed the output of compare in 7.1.1-44 (d85a7583f)
from some number <= 1 with 1 meaning the images are the same two two
numbers where the first is the distortion and the second one is the
old percentage in parenthesis. This breaks the test code in
https://sources.debian.org/src/xplanet/1.3.1-3/debian/tests/compare-create-> image/#L32 I assume that the new format will be kept so xplanet should adopt
the logic. Maybe something like:
result_jpg="$( compare -metric ncc $AUTOPKGTEST_TMP/expected/$filename.jpeg $AUTOPKGTEST_TMP/$filename.jpeg $AUTOPKGTEST_TMP/diff.jpg 2>&1 | sed 's/.*(\(.*\))/\1/' )"
2. imagemagick in stable returns values below 0 for similar but
different images. I did not check if this was different in older
versions but I would expect so, given that the autopkgtest code
checks the value for >0.99. This has been corrected by multiple
patches in imagemagick git main.
3. imagemagick in unstable has a bug resulting in the same picture
getting a percentage of 0 and different images a value of > 1. This
has also been corrected in imagemagick git main (912b6a838).
4. The results of earth_markers.* in the compare-create-image
autopkgtest improved (not sure due to what) so the files in
debian/tests/expected/earth_markers.* need to be replaced.
I think we have to accept that the output of compare is not stable and
adopt xplanet. I see two options what to do:
a. Adopt the xplanet to cope with any output of compare. This could be
either by just using the return value, hoping that the output on
different architectures is stable nowadays (I did not test this) or
by adding logic that only compares the number in case the return
value is not 0 (perfect match) and then try to interpret the
number(s).
b. Apply the imagemagick patches from git main and use the call from 1.
above.4
Cheers Jochen
Le vendredi 16 mai 2025, 13:31:55 heure d’été d’Europe centrale Jochen >Sprickerhof a écrit :
Hi,
* Paul Gevers <elbrus@debian.org> [2025-05-10 14:24]:
With a recent upload of imagemagick the autopkgtest of xplanet fails
in testing when that autopkgtest is run with the binary packages of
imagemagick from unstable. It passes when run with only packages from
testing. In tabular form:
pass fail
imagemagick from testing 8:7.1.1.47+dfsg1-1
xplanet from testing 1.3.1-3
all others from testing from testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of imagemagick to
testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package?
There are multiple problems:
1. imagemagick changed the output of compare in 7.1.1-44 (d85a7583f)
from some number <= 1 with 1 meaning the images are the same two two
numbers where the first is the distortion and the second one is the
old percentage in parenthesis. This breaks the test code in
https://sources.debian.org/src/xplanet/1.3.1-3/debian/tests/compare-create-> image/#L32 I assume that the new format will be kept so xplanet should adopt
the logic. Maybe something like:
result_jpg="$( compare -metric ncc
$AUTOPKGTEST_TMP/expected/$filename.jpeg $AUTOPKGTEST_TMP/$filename.jpeg
$AUTOPKGTEST_TMP/diff.jpg 2>&1 | sed 's/.*(\(.*\))/\1/' )"
2. imagemagick in stable returns values below 0 for similar but
different images. I did not check if this was different in older
versions but I would expect so, given that the autopkgtest code
checks the value for >0.99. This has been corrected by multiple
patches in imagemagick git main.
3. imagemagick in unstable has a bug resulting in the same picture
getting a percentage of 0 and different images a value of > 1. This
has also been corrected in imagemagick git main (912b6a838).
4. The results of earth_markers.* in the compare-create-image
autopkgtest improved (not sure due to what) so the files in
debian/tests/expected/earth_markers.* need to be replaced.
I think we have to accept that the output of compare is not stable and
adopt xplanet. I see two options what to do:
a. Adopt the xplanet to cope with any output of compare. This could be
either by just using the return value, hoping that the output on
different architectures is stable nowadays (I did not test this) or
by adding logic that only compares the number in case the return
value is not 0 (perfect match) and then try to interpret the
number(s).
b. Apply the imagemagick patches from git main and use the call from 1.
above.4
go b before hard freeze. Can I have git commit ?