I have to say the Fedora build farm is really talented at choosing a build target where one of the tests fails. What are the odds?! :)
By josch on 2020-06-27T21:48:41.438Z
In Debian we build architecture independent packages always on amd64. This has advantages and disadvantages. ;)
Unfortunately, I'm not able to reproduce this problem on Debian i386. Does it succeed on amd64 aka x86_64?
My hunch is, that the ^ Endianess: LSB$ is not only failing on i386 but also on other arches. The "TIFF float" check is the first of the TIFF checks. So maybe this is a problem with the imagemagick version and the version in Fedora just outputs something different for TIFF images?
That img2pdf version previously succeeded on Rawhide x86_64 thus I assumed it's just an x86 issue.
Looks now like imagemagick was updated in Rawhide in the meantime with a version that yields different verbose output.
By josch on 2020-06-28T11:02:02.918Z
I would like to move away from parsing identify -v but unfortunately I did not yet find any library with similar capabilities to imagemagick but a more stable interface.
The situation will be better with the next img2pdf release which transforms test.sh into test.py using pytest.
By Georg Sauthoff on 2020-06-29T19:36:55.518Z
Ok, I've commented out the test.sh call in Rawhide for now. With the next release I'll enable test.py then.
By Georg Sauthoff on 2020-06-29T19:38:56.133Z
Changed title: Test fails on {-32bit x86-} → Test fails on {+current Fedora Rawhide+}
By josch on 2020-07-02T21:19:31.164Z
For what it's worth, the bug will not be present anymore with the next img2pdf release. The problem is, that old imagemagick wrote:
Endianess: LSB
while the new one writes:
Endianness: LSB
So this is actually fixed by commit c6d04acc4b which was even written by you. :)
By Georg Sauthoff on 2020-07-06T19:08:59.368Z
So this is actually fixed by commit c6d04acc which was even written by you. :)
It was? O_O The commit header reads:
Authored by James R. Barlow about a month ago
Committed by josch about a month ago
By josch on 2020-08-04T07:15:28.323Z
Ah whoops, I must've had my head elsewhere when I wrote those lines. XD
Anyways, I'm closing this issue since it got fixed in commit c6d04acc by @jbarlow83
By josch on 2020-08-04T07:15:31.623Z
Status changed to closed
*By Georg Sauthoff on 2020-06-27T20:21:04.789Z*
I have another test failure on a kind of irrelevant architecture ... ;)
```
Test 27/51 TIFF float
+ echo 'Test 27/51 TIFF float'
+ convert /tmp/img2pdf.pETiftUQZN/normal.png -depth 32 -define quantum:format=floating-point /tmp/img2pdf.pETiftUQZN/float.tiff
+ identify -verbose /tmp/img2pdf.pETiftUQZN/float.tiff
+ grep --quiet '^ Format: TIFF (Tagged Image File Format)$'
+ identify -verbose /tmp/img2pdf.pETiftUQZN/float.tiff
+ grep --quiet '^ Mime type: image/tiff$'
+ identify -verbose /tmp/img2pdf.pETiftUQZN/float.tiff
+ grep --quiet '^ Geometry: 60x60+0+0$'
+ identify -verbose /tmp/img2pdf.pETiftUQZN/float.tiff
+ grep --quiet '^ Colorspace: sRGB$'
+ identify -verbose /tmp/img2pdf.pETiftUQZN/float.tiff
+ grep --quiet '^ Type: TrueColor$'
+ identify -verbose /tmp/img2pdf.pETiftUQZN/float.tiff
+ grep --quiet '^ Endianess: LSB$'
+ error
test 27 failed
intermediate data is left in /tmp/img2pdf.pETiftUQZN
+ echo test 27 failed
+ echo intermediate data is left in /tmp/img2pdf.pETiftUQZN
+ exit 1
```
cf. https://kojipkgs.fedoraproject.org//work/tasks/4972/46264972/build.log
I have to say the Fedora build farm is really talented at choosing a build target where one of the tests fails. What are the odds?! :)
---
*By josch on 2020-06-27T21:48:41.438Z*
---
In Debian we build architecture independent packages always on amd64. This has advantages and disadvantages. ;)
Unfortunately, I'm not able to reproduce this problem on Debian i386. Does it succeed on amd64 aka x86_64?
My hunch is, that the `^ Endianess: LSB$` is not only failing on i386 but also on other arches. The "TIFF float" check is the first of the TIFF checks. So maybe this is a problem with the imagemagick version and the version in Fedora just outputs something different for TIFF images?
---
*By Georg Sauthoff on 2020-06-28T07:32:40.039Z*
---
Indeed it also fails on x86_64 in a similar way: https://kojipkgs.fedoraproject.org//work/tasks/6357/46276357/build.log
(Note that both builds fail on Fedora Rawhide.)
That img2pdf version previously succeeded on Rawhide x86_64 thus I assumed it's just an x86 issue.
Looks now like imagemagick was updated in Rawhide in the meantime with a version that yields different verbose output.
---
*By josch on 2020-06-28T11:02:02.918Z*
---
I would like to move away from parsing `identify -v` but unfortunately I did not yet find any library with similar capabilities to imagemagick but a more stable interface.
The situation will be better with the next img2pdf release which transforms `test.sh` into `test.py` using pytest.
---
*By Georg Sauthoff on 2020-06-29T19:36:55.518Z*
---
Ok, I've commented out the `test.sh` call in Rawhide for now. With the next release I'll enable `test.py` then.
---
*By Georg Sauthoff on 2020-06-29T19:38:56.133Z*
---
Changed title: **Test fails on {-32bit x86-}** → **Test fails on {+current Fedora Rawhide+}**
---
*By josch on 2020-07-02T21:19:31.164Z*
---
For what it's worth, the bug will not be present anymore with the next img2pdf release. The problem is, that old imagemagick wrote:
Endianess: LSB
while the new one writes:
Endianness: LSB
So this is actually fixed by commit c6d04acc4bfc72906e7d7d71850a709da4c5debb which was even written by you. :)
---
*By Georg Sauthoff on 2020-07-06T19:08:59.368Z*
---
> So this is actually fixed by commit c6d04acc which was even written by you. :)
It was? O_O The commit header reads:
```
Authored by James R. Barlow about a month ago
Committed by josch about a month ago
```
---
*By josch on 2020-08-04T07:15:28.323Z*
---
Ah whoops, I must've had my head elsewhere when I wrote those lines. XD
Anyways, I'm closing this issue since it got fixed in commit c6d04acc by @jbarlow83
---
*By josch on 2020-08-04T07:15:31.623Z*
---
Status changed to closed
By Georg Sauthoff on 2020-06-27T20:21:04.789Z
I have another test failure on a kind of irrelevant architecture ... ;)
cf. https://kojipkgs.fedoraproject.org//work/tasks/4972/46264972/build.log
I have to say the Fedora build farm is really talented at choosing a build target where one of the tests fails. What are the odds?! :)
By josch on 2020-06-27T21:48:41.438Z
In Debian we build architecture independent packages always on amd64. This has advantages and disadvantages. ;)
Unfortunately, I'm not able to reproduce this problem on Debian i386. Does it succeed on amd64 aka x86_64?
My hunch is, that the
^ Endianess: LSB$
is not only failing on i386 but also on other arches. The "TIFF float" check is the first of the TIFF checks. So maybe this is a problem with the imagemagick version and the version in Fedora just outputs something different for TIFF images?By Georg Sauthoff on 2020-06-28T07:32:40.039Z
Indeed it also fails on x86_64 in a similar way: https://kojipkgs.fedoraproject.org//work/tasks/6357/46276357/build.log
(Note that both builds fail on Fedora Rawhide.)
That img2pdf version previously succeeded on Rawhide x86_64 thus I assumed it's just an x86 issue.
Looks now like imagemagick was updated in Rawhide in the meantime with a version that yields different verbose output.
By josch on 2020-06-28T11:02:02.918Z
I would like to move away from parsing
identify -v
but unfortunately I did not yet find any library with similar capabilities to imagemagick but a more stable interface.The situation will be better with the next img2pdf release which transforms
test.sh
intotest.py
using pytest.By Georg Sauthoff on 2020-06-29T19:36:55.518Z
Ok, I've commented out the
test.sh
call in Rawhide for now. With the next release I'll enabletest.py
then.By Georg Sauthoff on 2020-06-29T19:38:56.133Z
Changed title: Test fails on {-32bit x86-} → Test fails on {+current Fedora Rawhide+}
By josch on 2020-07-02T21:19:31.164Z
For what it's worth, the bug will not be present anymore with the next img2pdf release. The problem is, that old imagemagick wrote:
while the new one writes:
So this is actually fixed by commit
c6d04acc4b
which was even written by you. :)By Georg Sauthoff on 2020-07-06T19:08:59.368Z
It was? O_O The commit header reads:
By josch on 2020-08-04T07:15:28.323Z
Ah whoops, I must've had my head elsewhere when I wrote those lines. XD
Anyways, I'm closing this issue since it got fixed in commit
c6d04acc
by @jbarlow83By josch on 2020-08-04T07:15:31.623Z
Status changed to closed