Bug#1086224: RC: Argument " " isn't numeric in division (/) at /usr/share/perl5/GD/SecurityImage/Magick.pm

[Bastien Roucariès]

control: tags -1 + important

Le mardi 29 octobre 2024, 17:18:03 UTC gregor herrmann a écrit :
> On Tue, 29 Oct 2024 16:08:30 +0000, Niko Tyni wrote:
> 
> > This gives a list of thirteen integers on trixie, but
> > just one undef on sid.
> > 
> > Is this an intentional API change in ImageMagick 7 that GD::SecurityImage
> > should adapt to, or possibly a regression on the ImageMagick side?
> 
> Nice finding.
> 
> I also have a small info point to add.
> 
> The first of the 2 (now) failing test looks like this (same for the
> second in principle):
> 
> #v+
> # cat debian/tests/perlmagick-gd-7.q16
> #!/usr/bin/perl
> # regression test for #1032998
> use GD::SecurityImage use_magick => 1;
> 
> my $image = GD::SecurityImage->new(
>     width    => 200,
>     height   => 100,
>     lines    => 4,
>     gd_font  => 'Giant',
>     scramble => 1,
>     rndmax   => 10,
> );
> $image->random;
> $image->create( 'normal', 'default', "#403030", "#FF644B" );
> print $image->out( force => 'png' );
> #v-
> 
> Now GD::SecurityImage has two backends: GD::SecurityImage:GD has a
> gd_font property but GD::SecurityImage::Magick only has a font property
> (which needs an absolute path to a *.ttf file). And you are of course
> using the ::Magick backend :) (with use_magick => 1).
> 
> I wonder how this has ever worked; with use_magick gd_font attribute
> is never used (because it's in GD.pm) -- which amounts to Niko's
> finding where he used an empty 'font'.
> 
> 
> If I change your test to
> 
> #v+
> # cat debian/tests/perlmagick-gd-7.q16
> #!/usr/bin/perl
> # regression test for #1032998
> use GD::SecurityImage use_magick => 1;
> 
> my $image = GD::SecurityImage->new(
>     width    => 200,
>     height   => 100,
>     lines    => 4,
>     gd_font  => 'Giant',
>     font => '/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf',
>     scramble => 1,
>     rndmax   => 10,
> );
> $image->random;
> $image->create( 'normal', 'default', "#403030", "#FF644B" );
> print $image->out( force => 'png' );
> #v-
> 
> i.e. I add a 'font' value (and I picked DejaVuSans.ttf randomly as it
> was installed in the chroot where I built imagemagick; gd_font can be
> removed), it passes.
> 
> > > I suppose a depends on fonts is missing:
> > Please elaborate. Did ImageMagick 7 change something in (default?) font
> > handling? I couldn't easily find a summary of the changes.
> 
> My tenatative conclusion so far is:
> - The test was always incorrect, and passed by chance.
> - This luck is gone as apparently something changed in imagemagick.


imagemagick is fixed and return always a default font on debian.

So no more RC but a bug that need to be fixed in order to bail out early on undef.

I suppose if you pass an incorrect font it will still do the same

rouca
>  
> > > Moreinformation here:
> > > https://ci.debian.net/packages/i/imagemagick/testing/amd64/53694127/
> > Printing the generated image to the terminal at the end of your
> > autopkgtest check seems useless and clutters the log BTW.
> 
> Also my terminal :)
>  
> 
> Cheers,
> gregor
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://alioth-lists.debian.net/pipermail/pkg-perl-maintainers/attachments/20241105/497012ed/attachment.sig>