in ebuild we see: BACKENDS=( BACKEND_FREEIMAGE=$(usex freeimage) BACKEND_JPEG=$(usex jpeg) BACKEND_LIBPNG=$(usex png) BACKEND_LIBRSVG=$(usex svg) BACKEND_LIBTIFF=$(usex tiff) WINDOWS=${WINDOWS} ) but BACKEND_JPEG does nothing. Opening jpegs it uses FREEIMAGE. I guess "jpeg" IUSE activates libjpeg-turbo. It has to be changed to BACKEND_LIBJPEG. Corrected ebuild imv -h shows:s Name: libjpeg-turbo Description: Fast JPEG codec based on libjpeg. The software is based in part of the work of the Independent JPEG Group. Website: https://libjpeg-turbo.org/ License: The Modified BSD License I had issues with freeimage backend. For example imv dir/something.jpg resulted with no image (but it was possible to view something.jpg when imv dir).
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b3953d9995275aad3f34d2c389aade2ab61b9b7c commit b3953d9995275aad3f34d2c389aade2ab61b9b7c Author: Jeroen Roovers <jer@gentoo.org> AuthorDate: 2020-08-16 18:00:19 +0000 Commit: Jeroen Roovers <jer@gentoo.org> CommitDate: 2020-08-16 18:01:44 +0000 media-gfx/imv: Add USE=heif, use meson.eclass Package-Manager: Portage-3.0.2, Repoman-2.3.23 Bug: https://bugs.gentoo.org/show_bug.cgi?id=710344 Closes: https://bugs.gentoo.org/713682 Signed-off-by: Jeroen Roovers <jer@gentoo.org> media-gfx/imv/imv-9999.ebuild | 61 ++++++++++++++++++++----------------------- media-gfx/imv/metadata.xml | 1 + 2 files changed, 29 insertions(+), 33 deletions(-)
Is this "fixed" though? I wanted to invite comments after my changes, especially from the person who attached an ebuild implementing similar ideas slightly differently.
imv-9999[-freeimage,jpeg] correctly activates libjpeg-turbo. Now, it looks like freeimage cannot be used along with libjpeg-turbo, libpng or libtiff, but imho the original bug is fixed (no BACKEND_*). It was about a typo in ebuild (BACKEND_JPEG -> BACKEND_LIBJPEG).
