Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
View Bug Activity | Format For Printing | XML | Clone This Bug
I've tested media-gfx/eog (2.20.4 and 2.22.0) with jpeg useflag enabled but eog won't work with jpeg. Compiled fine but didn't work, I'm thinking a problem in ebuild. I have checked newer ver of media-libs/jpeg (6b-r7 and 6b-r8) but no sucess. Reproducible: Always Steps to Reproduce: 1.Compile media-gfx/eog with jpeg use flag enabled 2.Try to open jpeg file 3. Actual Results: jpeg file is not opened and a error message was showed: Could not load image X.jpg Unrecognized image file format Expected Results: jpeg file open sucessfully
I forgot emerge --info output: Portage 2.1.4.4 (default-linux/x86/2006.1, gcc-4.1.2, glibc-2.6.1-r0, 2.6.19-gentoo-r5 i686) ================================================================= System uname: 2.6.19-gentoo-r5 i686 Intel(R) Pentium(R) 4 CPU 2.66GHz Timestamp of tree: Sun, 29 Jun 2008 16:19:01 +0000 ccache version 2.4 [enabled] app-shells/bash: 3.2_p17-r1 dev-lang/python: 2.4.4-r6 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r7 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.22-r2 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium4 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -march=pentium4 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="ccache collision-protect distlocks metadata-transfer parallel-fetch sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="ftp://ftp.wh2.tu-dresden.de/pub/mirrors/gentoo " LANG="en_US" LC_ALL="en_US" LINGUAS="en es_ES es" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="alsa berkdb cli cracklib cups dbus doc foomaticdb gdbm gnome gpm gtk hal iconv isdnlog midi mmx mudflap ncurses nls nptl nptlonly nvidia opengl openmp pcre perl ppds pppd python readline reflection session spl sse sse2 ssl tcpd unicode x86 xorg zlib" ALSA_CARDS="ens1371" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en es_ES es" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
I see the following possibilities: 1) your system is corrupted 2) your photo is corrupted 3) the mime bug, see bug #228885
(In reply to comment #2) > I see the following possibilities: > 1) your system is corrupted I'm thinking eog is not using jpeg library correctly > 2) your photo is corrupted GIMP are able to open the file by default (clicking on it) > 3) the mime bug, see bug #228885 jpeg files are open with GIMP by default correctly Could I do some test to find problem please?
(In reply to comment #3) > (In reply to comment #2) > > I see the following possibilities: > > 1) your system is corrupted > I'm thinking eog is not using jpeg library correctly* eog would be useless if it couldn't handle jpeg... > > 2) your photo is corrupted > GIMP are able to open the file by default (clicking on it) ok > > 3) the mime bug, see bug #228885 > jpeg files are open with GIMP by default correctly > Could I do some test to find problem please? yeah, apply the fix that is described in the bug report (update-mime-database). And try to open the photo again. If the app asks what's the mimetype of the file and is returned text/plain, it's only logical it fails with the error you described.
(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > I see the following possibilities: > > > 1) your system is corrupted > > I'm thinking eog is not using jpeg library correctly* > eog would be useless if it couldn't handle jpeg... > > > > 2) your photo is corrupted > > GIMP are able to open the file by default (clicking on it) > ok > > > > 3) the mime bug, see bug #228885 > > jpeg files are open with GIMP by default correctly > > Could I do some test to find problem please? > > yeah, apply the fix that is described in the bug report (update-mime-database). > And try to open the photo again. If the app asks what's the mimetype of the > file and is returned text/plain, it's only logical it fails with the error you > described. > I have tried updating mime database (and a lot of things) but its as if eog wouldn't support for jpeg files. Mimetype is correct (jpeg) but eog wasn't able to open it. Same errors: "Could not load image 'screenshot55.jpeg'. Unrecognized image file format." I have checked, with ldd, jpeg and libexif but nothig strange. No idea. Please, could I do another kind of test? I'm thinking is another kind of bug that you shown me :S
User 'Hopeless' solved it at forums (here:http://forums.gentoo.org/viewtopic-t-647639-highlight-eog+jpeg.html?sid=3092656cc4ab3fdddcefd8f8784df04bhttp://forums.gentoo.org/viewtopic-t-647639-highlight-eog+jpeg.html?sid=3092656cc4ab3fdddcefd8f8784df04b) There is a dependence which is not checked, x11-libs/gtk+ needs jpeg USE flag activated, but this is not currently checked nor requested when eog is installed (another ebuilds just request necessary use flags at install time)
*** Bug 232626 has been marked as a duplicate of this bug. ***
This appears to be a valid bug. Rebuilding gtk+ with USE=jpeg does fix this problem (eog doesn't need to be rebuilt). @herd, is it okay if I add an ewarn if USE=jpeg is enabled and gtk+ isn't built with USE=jpeg? We _could_ die in this case, but IMO we should avoid die'ing if possible. I guess we can just do this in 2.22.3 since it should become stable soon enough.
(In reply to comment #8) > This appears to be a valid bug. Rebuilding gtk+ with USE=jpeg does fix this > problem (eog doesn't need to be rebuilt). > > @herd, is it okay if I add an ewarn if USE=jpeg is enabled and gtk+ isn't built > with USE=jpeg? We _could_ die in this case, but IMO we should avoid die'ing if > possible. > > I guess we can just do this in 2.22.3 since it should become stable soon > enough. > Thanks, user become lost if system request USE flag on some packages and don't request it on another (which need it) This bug is solved by my side :) Please I have to mark it fixed now or you doing it when completed?
(In reply to comment #9) [...] > Thanks, user become lost if system request USE flag on some packages and don't > request it on another (which need it) This bug is solved by my side :) Please I > have to mark it fixed now or you doing it when completed? The protocol is generally that a developer will commit the fix and then mark the bug as fixed. It turns out that the 'jpeg' USE flag actually controlled EXIF reading/writing. I've renamed it to 'exif'. The ebuild now also issues a warning if x11-libs/gtk+ is built without the jpeg/tiff USE flags.
> The protocol is generally that a developer will commit the fix and then mark > the bug as fixed. > > It turns out that the 'jpeg' USE flag actually controlled EXIF reading/writing. > I've renamed it to 'exif'. The ebuild now also issues a warning if > x11-libs/gtk+ is built without the jpeg/tiff USE flags. > OK, thanks you very much for your time
