When I don't have imagemagick installed and attempted to emerge the noto-emoji package I get: -- >>> Source configured. >>> Compiling source in /var/tmp/portage/media-fonts/noto-emoji-20180814/work/noto -emoji-3ffd20ec7504657aa17c84f9aa475ad09b20c362 ... make --jobs=5 --load-average=5.64 which: no optipng in (/var/tmp/portage/media-fonts/noto-emoji-20180814/temp/python 2.7/bin:/usr/lib/portage/python3.6/ebuild-helpers/xattr:/usr/lib/portage/python3.6 /ebuild-helpers:/usr/lib/llvm/7/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/ bin:/sbin:/bin:/opt/bin:/usr/sbin:/usr/bin:/bin:/sbin) mkdir -p "build/emoji" mkdir -p "build/quantized_pngs" mkdir -p "build/compressed_pngs" using zopflipng cc waveflag.c -o waveflag `pkg-config --cflags --libs cairo` -lm `pkg-config --li bs cairo` mkdir -p "build/flags" mkdir -p "build/resized_flags" mkdir -p "build/renamed_flags" /bin/sh: convert: command not found make: *** [Makefile:179: build/emoji/emoji_u1f468_200d_1f3a8.png] Error 127 * ERROR: media-fonts/noto-emoji-20180814::gentoo failed (compile phase): * emake failed -- After first emerging media-gfx/imagemagick the build succeeds. -- # emerge -p media-fonts/noto-emoji These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] media-fonts/noto-emoji-20180814 USE="-X" --
Created attachment 551334 [details] fixed ebuild added build dependency on media-gfx/imagemagick
(In reply to Albert W. Hopkins from comment #0) > make --jobs=5 --load-average=5.64 > which: no optipng in > (/var/tmp/portage/media-fonts/noto-emoji-20180814/temp/python > ... > using zopflipng Is there a significant difference in installed file size between media-gfx/optipng and app-arch/zopfli? Seems like the ebuild should prevent automagic detection of the former when it has a hard depend on the latter.
(In reply to Anthony Parsons from comment #2) > (In reply to Albert W. Hopkins from comment #0) > > > make --jobs=5 --load-average=5.64 > > which: no optipng in > > (/var/tmp/portage/media-fonts/noto-emoji-20180814/temp/python > > ... > > using zopflipng > Is there a significant difference in installed file size between > media-gfx/optipng and app-arch/zopfli? Seems like the ebuild should prevent > automagic detection of the former when it has a hard depend on the latter. even with optipng it won't get used automagically, zopfli is always preferred except if exporting a variable as upstream prefers it because of the extra quality that supposedly gives to the generated files
(In reply to tao from comment #1) > Created attachment 551334 [details] > fixed ebuild > > added build dependency on media-gfx/imagemagick Can you try to see if also media-gfx/graphicsmagick works for that? Thanks
(In reply to Pacho Ramos from comment #3) > even with optipng it won't get used automagically, zopfli is always > preferred except if exporting a variable as upstream prefers it because of > the extra quality that supposedly gives to the generated files Alright, sounds like it's fine as-is. That answers my question then, thanks. (In reply to Pacho Ramos from comment #4) > (In reply to tao from comment #1) > > Created attachment 551334 [details] > > fixed ebuild > > > > added build dependency on media-gfx/imagemagick > > Can you try to see if also media-gfx/graphicsmagick works for that? Thanks It needs media-gfx/graphicsmagick[imagemagick] (the "convert" command is only installed with that compat USE flag set), but it appears to work fine.
(In reply to Anthony Parsons from comment #5) > It needs media-gfx/graphicsmagick[imagemagick] (the "convert" command is > only installed with that compat USE flag set), but it appears to work fine. Never mind, that was a bit premature. It looks like the "canvas:none" used in the command line causes graphicsmagick issues, I'll see if I can figure out what that's meant to do and work around it.
Alright, I think I jumped the gun there. On closer inspection this might not work in graphicsmagick without serious work beyond my ability: - "canvas:none" is used but isn't valid in gm. Replacing it with "xc:transparent" is reported to be equivalent, and the command succeeds, but - "-composite" isn't a switch in graphicsmagick and there's no direct equivalent. From what I'm reading it would need to be split into separate convert/composite commands, and I'm not enough of an expert in this stuff to figure that out. Any attempts I've tried just generate blank images. Looks like imagemagick is the only option for the time being.
Created attachment 551436 [details, diff] noto-emoji-use-gm.patch Fedora is using this patch as they use graphicsmagick... we could apply it conditionally when graphicsmagick is used and support both I think Can you try it? Thanks
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a3a00933657efc59adb45c0a1e89f030be5de83f commit a3a00933657efc59adb45c0a1e89f030be5de83f Author: Pacho Ramos <pacho@gentoo.org> AuthorDate: 2018-10-20 09:11:32 +0000 Commit: Pacho Ramos <pacho@gentoo.org> CommitDate: 2018-10-20 11:38:50 +0000 media-fonts/noto-emoji: Allow to build with graphicsmagick Thanks-to: Albert W. Hopkins Thanks-to: Anthony Parsons Closes: https://bugs.gentoo.org/668718 Signed-off-by: Pacho Ramos <pacho@gentoo.org> Package-Manager: Portage-2.3.51, Repoman-2.3.11 .../noto-emoji/files/noto-emoji-use-gm.patch | 30 ++++++++++++++++++++++ media-fonts/noto-emoji/noto-emoji-20180814.ebuild | 6 +++++ 2 files changed, 36 insertions(+)
