Opened 14 months ago

Closed 14 months ago

Last modified 14 months ago

#5593 closed defect (wontfix)

Fails to build with imagemagic 6.9.12.98

Reported by: sebastic Owned by: strk
Priority: medium Milestone: PostGIS 3.4.1
Component: build Version: 3.4.x
Keywords: Cc: sebastic

Description

As reported in Debian Bug #1054715:

During a rebuild of all packages in sid, your package failed to build on amd64.

Relevant part (hopefully):

make[3]: Entering directory '/<<PKGBUILDDIR>>/doc/html/images'
x86_64-linux-gnu-gcc -I../../../liblwgeom -I../../../liblwgeom  -I/usr/include -I/usr/include/x86_64-linux-gnu -I/usr/include/webp   -I/usr/include/libxml2 -I/usr/include -I/usr/include/json-c   -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 -std=gnu99 -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -fno-math-errno -fno-signed-zeros -Wall -flto -I/usr/include/x86_64-linux-gnu -I/usr/include/webp  -c -o styles.o styles.c
x86_64-linux-gnu-gcc -I../../../liblwgeom -I../../../liblwgeom  -I/usr/include -I/usr/include/x86_64-linux-gnu -I/usr/include/webp   -I/usr/include/libxml2 -I/usr/include -I/usr/include/json-c   -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 -std=gnu99 -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -fno-math-errno -fno-signed-zeros -Wall -flto -I/usr/include/x86_64-linux-gnu -I/usr/include/webp  -c -o generator.o generator.c
/bin/bash ../../../libtool --mode=link \
x86_64-linux-gnu-gcc -o generator styles.o generator.o ../../../liblwgeom/.libs/liblwgeom.a -Wl,-z,relro -Wl,-z,now -lm -flto -L/usr/lib/x86_64-linux-gnu -lgeos_c -lproj  
libtool: link: x86_64-linux-gnu-gcc -o generator styles.o generator.o -Wl,-z -Wl,relro -Wl,-z -Wl,now -flto  ../../../liblwgeom/.libs/liblwgeom.a -lm -L/usr/lib/x86_64-linux-gnu -lgeos_c -lproj
convert-im6.q16: attempt to perform an operation not allowed by the security policy `@generator-REtQrw/draw0' @ error/string.c/FileToString/1020.
Failure return code (1) from command: convert -size 200x200 xc:none -fill none -stroke "#6495ED" -strokewidth 4 -draw '@generator-REtQrw/draw0' -flip generator-REtQrw/tmp0.pngreading styles from wkt/styles.conf
generating de9im01.png
make[3]: *** [Makefile:261: de9im01.png] Error 1

The full build log is available from: http://qa-logs.debian.net/2023/10/27/postgis_3.4.0+dfsg-2_unstable.log

The imagemagick package was recently updated from 6.9.11.60 to 6.9.12.98 in Debian unstable.

Change History (7)

comment:1 by strk, 14 months ago

These security policy errors I've often stumbled upon and always had to fix by tweaking /etc/ImageMagick-*/policy.xml so this would sound like a system configuration issue.

See https://stackoverflow.com/questions/52998331/imagemagick-security-policy-pdf-blocking-conversion

That said, if we can stop using convert commandline that could also fix the problem and make images generation faster.

comment:2 by strk, 14 months ago

Resolution: wontfix
Status: newclosed

I'm closing as a wontfix as this should be fixed at the distribution side (and I see it's marked as fixed already).

Any contribution toward removing the execution of external executable would be welcome.

comment:3 by sebastic, 14 months ago

Just for the record, it's not fixed, only worked around by using graphicsmagick instead of imagemagick.

comment:4 by robe, 14 months ago

What's the difference between graphicsmagick and imagemagick? Should we be moving towards graphicsmagick

comment:5 by mdavis, 14 months ago

Or should we switch to including the image file (PNG or maybe also SVG) in the repo? So that only documentation maintainers need to generate images.

in reply to:  4 comment:6 by sebastic, 14 months ago

Replying to robe:

What's the difference between graphicsmagick and imagemagick?

See: http://www.graphicsmagick.org/FAQ.html#how-does-graphicsmagick-differ-from-imagemagick

Should we be moving towards graphicsmagick

That would likely avoid issues like #5446.

comment:7 by strk, 14 months ago

I'm generally against adding non-source files in source code repositories.

My understanding is that graphicsmagick has the same executable names as imagemagick so no change is needed on our side to use one rather than the other. Whether graphicsmagick works by luck or by design in this case I'm not sure (could Debian have more sensible configuration for one and not for the other when it comes to the policy.xml file?)

Note: See TracTickets for help on using tickets.