Package Details: imagemagick-full 7.1.1.41-1

Git Clone URL: https://aur.archlinux.org/imagemagick-full.git (read-only, click to copy)
Package Base: imagemagick-full
Description: An image viewing/manipulation program (Q32 HDRI with all possible features)
Upstream URL: https://www.imagemagick.org/
Keywords: convert graphics image imagemagick photo
Licenses: LicenseRef-custom
Conflicts: imagemagick, libmagick
Provides: imagemagick, libmagick, libmagick-full
Replaces: libmagick-full
Submitter: dbermond
Maintainer: dbermond
Last Packager: dbermond
Votes: 17
Popularity: 0.000001
First Submitted: 2015-12-27 13:40 (UTC)
Last Updated: 2024-11-18 16:35 (UTC)

Dependencies (98)

Required by (1074)

Sources (2)

Latest Comments

1 2 3 4 5 Next › Last »

dbermond commented on 2024-06-16 00:21 (UTC)

@korimitsu this is a problem with upstream libultrahdr, and not with ImageMagick, and neither a packaging issue. I have pushed a fix for libultrahdr-git, and now the package is building fine when using it.

korimitsu commented on 2024-06-15 22:47 (UTC)

Fails to build:

  CCLD     coders/tiff.la
  CC       coders/uhdr_la-uhdr.lo
In file included from coders/uhdr.c:47:
/usr/include/ultrahdr_api.h:320:72: error: unknown type name 'bool'
  320 |                                                                        bool use_multi_channel_gainmap);
      |                                                                        ^~~~
/usr/include/ultrahdr_api.h:1:1: note: 'bool' is defined in header '<stdbool.h>'; this is probably fixable by adding '#include <stdbool.h>'
  +++ |+#include <stdbool.h>
    1 | /*
make[1]: *** [Makefile:11408: coders/uhdr_la-uhdr.lo] Error 1
make[1]: Leaving directory '/home/user/.cache/paru/clone/imagemagick-full/src/ImageMagick-7.1.1-33'
make: *** [Makefile:6259: all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...
error: failed to build 'imagemagick-full-7.1.1.33-1': 
error: packages failed to build: imagemagick-full-7.1.1.33-1

dbermond commented on 2024-05-17 15:20 (UTC)

@Nact @jpgeee @korimitsu try to build using pstoedit-nomagick and autotrace-nomagick. Also, make sure that your magickcache-git is linked against imagemagick-full, and not against the repository imagemagick (you need to build it two times, due to the circular dependency).

korimitsu commented on 2024-05-17 11:25 (UTC)

Fails to build:

In file included from /usr/include/librsvg-2.0/librsvg/rsvg.h:1458:
/usr/include/librsvg-2.0/librsvg/rsvg-cairo.h:90:10: note: declared here
   90 | gboolean rsvg_handle_render_cairo (RsvgHandle *handle, cairo_t *cr);
      |          ^~~~~~~~~~~~~~~~~~~~~~~~
  CCLD     coders/svg.la
/usr/bin/ld: cannot find -lMagickCore-7.Q16HDRI: No such file or directory
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:7868: coders/svg.la] Error 1
make[1]: Leaving directory '/home/sam/.cache/paru/clone/imagemagick-full/src/ImageMagick-7.1.1-32'
make: *** [Makefile:6264: all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...
error: failed to build 'imagemagick-full-7.1.1.32-1': 
error: packages failed to build: imagemagick-full-7.1.1.32-1

jpgeee commented on 2024-05-17 07:39 (UTC)

Same problem as Nact.

Nact commented on 2024-04-25 15:18 (UTC) (edited on 2024-04-25 15:19 (UTC) by Nact) 

ok
PASS: Magick++/tests/tests.tap 1
Testing throwing and catching exceptions. A program crash or a message
that the exception was not caught indicates a test failure.  A properly
formatted exception message indicates success:
Caught exception, good!:
  "attributes: unable to open image 'foo': No such file or directory @ error/blob.c/OpenBlob/3571"
ok
PASS: Magick++/tests/tests.tap 2
ok
PASS: Magick++/tests/tests.tap 3
ok
PASS: Magick++/tests/tests.tap 4
Caught exception: coderInfo: unable to load module '/home/..../imagemagick-full/src/ImageMagick-7.1.1-31/coders/svg.la': file not found @ error/module.c/OpenModule/1293
not ok
FAIL: Magick++/tests/tests.tap 5

Anyone running into this?

dbermond commented on 2023-12-10 01:23 (UTC)

@frankspace using symlinks for different libraries is not a good practice and should be avoided. This can lead to unpredictable results and crashes.

dbermond commented on 2023-12-10 01:23 (UTC)

@dreieck regarding libumem, it does not make any difference, as there is no stable libumem package, and probably there will not be, as upstream libumem is abandoned and very old. Also, libumem builds in linux only with some unsupported patches, and I cannot remember if they apply to the old tagged version (probably not, as patches are based on git master). Removing imagemagick from provides is technically correct, but that's not so simple in this case. This package must conflict with imagemagick, and being such, any package that depends on imagemagick will not be able to use this one if it would not provide imagemagick. As far as I understand, making it to install alongside with repository imagemagick is not trivially possible, as the configuration files in '/etc' will conflict, and I'm not aware of a supported upstream way to specify a different directory for these files. A good reasonable solution is to make it provide imagemagick and let the user build/rebuild target packages against it, although being technically incorrect since it does not provide the same Q16 libraries.

frankspace commented on 2023-12-07 14:41 (UTC)

@dreieck and @dbermond, this is probably a very stupid question, but regarding 32-bit/16-bit compatibility, is there any particular reason why the distinction would actually break anything if you just added some symlinks? For example, ln -s /usr/lib/libMagickCore-7.Q32HDRI.so ${pkgdir}/usr/lib/libMagickCore-7.Q16HDRI.so and so on? That's literally what the official libudev0-shim package does, after all. And maybe it would break; I genuinely don't know. (This has nothing to do with the libumem or magickcache stuff, just the bit depth stuff.) If shimming wouldn't break anything, that'd seem to solve that particular problem, wouldn't it?

dreieck commented on 2023-11-07 19:19 (UTC) (edited on 2023-11-07 19:20 (UTC) by dreieck)

There is no libumem and magickcache stable packages, so the only option is depending on libumem-git and magickcache-git.

The conclusion is wrong. libumem-git provides libumem, magickcache-git provides magickcache. So the -git packages wills suffice to satisfy the dependencies.

If there would be a magickcache stable package, it currently needs code that is only in the magickcache git master branch, and will not compile with the old magickcache release from 2022

That is a valid argument to use magickcache-git over magickcache.
Does the same hold true for libumem-git?

Being a -full package, it uses 32-bit depth by design and does not provide 16-bit depth, so you need to recompile anything that needs the 16-bit depth libraries

Then you must remove the imagemagick and libmagick provides entries, since it is not a drop-in replacement for Arch Linux' imagemagick: Other Arch Linux repo software will not work.

You then should adapt the package that it can be installed in parallel with the stock imagemagick.

E.g. rename it to "imagemagick-32bit-full" or something similar.

Regards and thanks for the package!

1 2 3 4 5 Next › Last »