Legacy ImageMagick Discussions Archive

I have asked my hosts to upgrade Imagemagick and they have come back with the below. Is there a quick piece of code that I can run to prove whether I am using a 6.7 or 6.9 version?

Have you tested your code against the standard binary since changing PHP version? CentOS/Redhat use a software management methodology referred to as back porting. A 'base' version is used and additional features and bug fixes are introduced or "back ported" without a major version change (it's an enterprise approach to patching). Whilst this means the advertised version is 'old', it's actually up to date in regards to patching (and potentially features too). You can see this in the version response:

> 6.7.2-7 2017-03-23 Q16

Perhaps I misunderstand, but just do
Or perhaps they have put the new version in another directory that you may have to reference. You can see what the IM locations are using
Often one version is at /usr/local/bin/convert and another may be at /usr/bin/convert

The result of convert -version is at the bottom of the first post.

From what I have read Centos installs a version of software and then keeps patching it and that is why the version is 6.7.2-7 but the date is 2017-03-23. Presumably the last patch was on that date.

But does Imagmagick put out patches for upgrades and if so why does it not update the version tag?

I do not want to go through all my codes trying to find a problem and that is why I wanted some bit of code I could try that would work in V6.9 but not V6.7 A new option or change in a command would be nice.

I can not find a link to the full V6 change log so I can select something to try.

http://legacy.imagemagick.org/script/changelog.php for IM 6 changelog

Radial-gradients were a new feature at 6.9.2-5: The result should be red at top-left, blue at bottom-right.

Off to a good start and found a bug in my latest version of Imagemagick 7.0.3 Q16 on my PC. This bug is back and I get it with convert and magick:
https://bugs.debian.org/cgi-bin/bugrepo ... bug=849507

This stroke also sort of works but the text goes off the image: https://www.imagemagick.org/discourse-s ... =3&t=29626

But it works OK on my server Soooo that means my server must be on a version later than 6.9.4-5?

It would be interesting if Magick could comment on this.

Thank you for your example snibgo and that fails which is strange - I have a gradient red at the top and blue at the bottom.
It works on my localhost with V7.0.3 and whatever convert version it comes with.

Very strange; I hate testing.

The -monochrome gif works in V7.0.5 and so it must be fixed again but convert will not work ( in a hurry and forgot to tick legacy programs box ).

Bonzo wrote:Thank you for your example snibgo and that fails which is strange - I have a gradient red at the top and blue at the bottom.

So, your version hasn't implemented "-define gradient:direction".

If your hosts update IM by applying patches to an old version, I suppose they might apply some patches but not others.

It seems an easy way to keep on top of the imagemagick versions etc. but I would like to know how and what patch's they get. I assume Magick must issue patch's but do they include everything? It does not look as though they do as the gradient is not working. It would also be good if it could change the Imagemagick version number. Otherwise we tell the OP to upgrade as his version is to old but in fact it could be up to date.

From my hosts:

Unfortunately we don't maintain these packages, they're supplied directly from CentOS/Redhat and CloudLinux. Bug fixes will be applied as/when we receive them from the software vendors involved.

So in fact it could be a bit of a hit amd miss method and as everyone knows it is not good to keep patching things; sometimes you need to start again.

User "magick" may comment.

The source code contains the version number, so this is clearly one source code change that your host hasn't applied.

I don't know how ImageMagick patches are made, catalogued, or applied. Or how dependencies between patches are documented. A distributor such as Redhat may maintain dependency lists between patches of a large number of software products. Eek -- this seems very complex.

To me, it doesn't seem reasonable to use a software product such as IM without knowing what version it is, so I wouldn't know what version of the documentation or source code applies.

I have been talking to my hosts again and they say:

The patching approach (backporting) won't be influenced by ImageMagick themselves, it's a method adopted by the operating system vendors (primarily for enterprise).

The hosts have installed a 6.9.4-10 Q16 x86_64 2017-01-13 version for me to test and the gradient works with it. It fails with the 6.7.2-7 2017-03-23 Q16 version which is supposed to be patched up to date.
I will have another look at it later to make sure I am not doing anything stupid but this could be a nightmare if it is the case that Redhat/Centos implement what they want.