A few test case failures on Fedora 37 with ImageMagick 7 #152
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Fedora just recently switched to ImageMagick 7.
It looks like the switch caused some test cases to fail (from a Fedora Rawhide, i.e. future Fedora 38 build):
Full log: https://kojipkgs.fedoraproject.org//work/tasks/5655/96035655/build.log
ImageMagick version: ImageMagick 1:7.1.0.57-1.fc38
Img2pdf version: 0.4.4
Ok, I added the following patch to fix the ValueError:
The still failing tests can then be selected by the following pytest expression (
-k
):I also tested it on Fedora 37 (i.e. still ImageMagick-6.9.12.70-1.fc37.x86_64) and there the following tests also fail:
In addition to that, some additional test cases fail when running them on PPC64LE.
(The Fedora build system builds noarch Python packages such as img2pdf not on all supported architectures, but picks a build server basically by chance - thus the tests run on rather niche architectures, only from time to time.)
https://kojipkgs.fedoraproject.org//work/tasks/1918/96531918/build.log
That means the 'endianess' is always reported as
MSB
instead of the expectedLSB
.I haven't looked at it in detail, but it's a bit curious since - although it rund on the nowadays esoteric PPC architecture - it's running in PPC little-endian mode.
The ValueError part of this issue should be fixed by
57d7e07e6b
Can you confirm?
The endianness problems also occurred on s380x (also big endian) and were fixed in
33139612f8
I'm afraid the endianess issue is more involved than it seems and thus the s390x fix isn't sufficient:
https://github.com/ImageMagick/ImageMagick/issues/6300
tl;dr: IM7 currently creates big-endian byte order TIFFs on non x86 archs by default, i.e. little-endian ones! And the IM plan is to even switch to write litte-endian TIFFs on all archs, by default.
So if the TIFF byte order is important to img2pdf perhaps it makes sense to explicitly specify it via an ImageMagick command line option.
Oh dear...
Okay, but the commit I referenced above is sufficient to fix this issue right now, correct? Though it will break in the future once IM7 decides to write little-endian TIFF on all arches.
TIFF byte order is not always important but it sometimes is. For the cases where it is, the test suite creates them by passing
-define tiff:endian=msb -define tiff:fill-order=msb
or-define tiff:endian=lsb -define tiff:fill-order=lsb
to imagemagick. Those are the only cases where checking the byte order for the correct values is crucial.No, unfortunately, it's not.
Currently, I'm working around it in the Fedora rawhide builds like this:
Otherwise the build fails on aarch64 and ppc64le, which are little-endian architectures - because current IM7 thinks they are big-endian and the img2pdf tests correctly detect the host as little-endian.
IIRC, I even did try to add a IM convert option for explicitly selecting the TIFF byte order, but this lead to other failed assertions.
NB: s390x is big-endian, and probably the last architecture that isn't completely dead, yet.
NB: On Fedora, a Python package like img2pdf is a so called noarch package and thus it's build on one of the supported target archs, by chance - i.e. not on all of them.
Thus, it sometimes takes a few builds before noticing such issues. However, it's also possible to explicitly build a package on a certain arch for testing, and this is what I did after I noticed these issues.
ah then this is an IM7 issue because i tested the current git HEAD on Debian with IM6 and the tests work fine on aarch64, ppc64el as well as s390x.
can i prepare another patch for you which completely removes the byte-order check for those tests where it doesn't matter so that you can test this with fedora IM7 on those architectures?
Yes, I can test such a patch.
Excellent, thank you! Here it is:
https://paste.debian.net/hidden/355d54e1/
This skips the endianness check for all images where img2pdf should not care.
Sorry, it took me some time to get back to this.
Unfortunately, debian pastebin has already removed the patch, it seems.
Can you post it again, e.g. perhaps attach it to this issue?
Thank you, attached! 😄
Hm, the patch doesn't apply on top of 0.4.4.
Ok, I've did a scratch build on aarch64 with the current main branch and that patch on top:
https://kojipkgs.fedoraproject.org//work/tasks/3250/103743250/build.log
AFAICS, the endian errors are gone, but there are some other errors and failures.
There seem to be 2 causes:
baseType
beingNone
/usr/share/color/icc/sRGB.icc
not being availableExamples:
On Fedora there doesn't seem to be a package that provides that exact path.
However, there is colord which provides
/usr/share/color/icc/colord/sRGB.icc
, icc-profiles-openicc which provides/usr/share/color/icc/OpenICC/sRGB.icc
, among others.Thank you for your tests! For what it's worth, my own computer is also an arm64 machine, so it is more likely for architecture specific problems on amd64/x86_64 to creep up because I don't have an intel machine at home anymore. The remaining problems are specific to imagemagick and fedora.
Oh no... this sounds like imagemagick changed one of the key names in its json output again without bumping the format version... Could you run this command on some true-color and have a look in the output what the new name of the key is that has the "TrueColor" value?
I recently added this commit:
29921eeabd
It tries to see if some common locations for sRGB.icc are available and picks the first one. Is one location that is used in Fedora missing from that list?
Thanks!
I just pushed a commit with the patch I attached in an earlier message.
This does not yet fix the baseType bug (I need to know what you get when you run
convert truecolor.jpg json:
to fix this) and it doesn't fix the sRGB.icc path issue (probably we just need to add the Fedora specific path to the list).@gms do you think you will manage to look into those two things soon? Otherwise I'll just do another release first. Thanks!
Sure, this is from a Fedora 38 system:
Vs. Fedora 37:
Which have same key, it looks.
I'll also check current Fedora Rawhide in a minute.
Fedora has
/usr/share/color/icc/OpenICC/sRGB.icc
and/usr/share/color/icc/colord/sRGB.icc
via icc-profiles-openicc and colord. However, I'll have to explicitly declare one of them as build dependency because otherwise the package/profile isn't available in the build chroot. I'll add icc-profiles-openicc as build dependency.The ImageMagick verison isn't much newer on Rawhide and yields the same results AFAICS:
I don't know if this helps and how good the podman experience is on debian, but this is a simple way to locally try out userspace on Fedora Rawhide:
Hrm... odd that it doesn't work for you then. Commit
29921eeabd
added both these paths to the search paths and will pick up the first one it finds.I heard that other Debian people successfully are using podman. could you give me a command to run that installs all the runtime dependencies of img2pdf once i'm inside that container? Thanks!
It should work. It's just that I wasn't aware of this change and I thus hadn't modified the build dependencies. Thus, all the builds until now executed in a build environment that didn't include any of the mentioned dependencies.
For sure with the next revision I'll push I'll add that icc-profiles-openicc dependency.
You can install dependencies via:
Currently, this pulls in 211 MiBs or so of RPMs, in a fresh container.
Note that the
--rm
switch automatically removes the container after exiting the shell, which might be unexpected and/or unwanted for some work.Thank you, I'm able to reproduce the problem with rawhide inside podman:
Okay,
e05580a49a
fixes the baseType problem. I can also confirm that installingicc-profiles-openicc
makes the tests succeed that failed before.Unfortunately, now new tests start failing. The ones I added because img2pdf now understands JPEG2000 files with transparency:
Sigh...