nautilus-2.8.2-r1 display (with blender created) tga images horizontaly flipped in preview. After I opened a image (with gimp-remote) it's displayed correct in preview. emerge -vp nautilus These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] gnome-base/nautilus-2.8.2-r1 +cups -debug +flac +gstreamer +mad +oggvorbis 5,672 kB > emerge info Portage 2.0.51-r15 (default-linux/x86/2004.3, gcc-3.3.5, glibc-2.3.4.20040808-r1, 2.6.10-gentoo-r6-1 i686) ================================================================= System uname: 2.6.10-gentoo-r6-1 i686 AMD Duron(tm) Gentoo Base System version 1.4.16 Python: dev-lang/python-2.2.3-r5,dev-lang/python-2.3.4-r1 [2.3.4 (#1, Feb 9 2005, 23:22:02)] distcc 2.16 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] ccache version 2.3 [enabled] dev-lang/python: 2.2.3-r5, 2.3.4-r1 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.4 sys-devel/binutils: 2.15.92.0.2-r1 sys-devel/libtool: 1.5.10-r4 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distcc distlocks sandbox sfperms" GENTOO_MIRRORS="ftp://ftp.easynet.nl/mirror/gentoo/ http://ftp.easynet.nl/mirror/gentoo/ http://gentoo.inode.at/ ftp://gentoo.inode.at/source/" LANG="de_DE@euro" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 3dnow X aalib acpi alsa apm athena avi berkdb bitmap-fonts bonobo cairo cdr crypt cscope cups curl dga directfb dmx dnd doc dv dvd encode esd f77 faad fam fbcon flac font-server foomaticdb fortran freetype gdbm ggi gif gnome gphoto2 gpm gstreamer gtk gtk2 gtkhtml guile hal imagemagick imlib ipv6 java joystick jpeg jpeg2k kde ldap libcaca libg++ libsamplerate libwww mad maildir mbox mikmod mmx mozilla moznoirc moznomail mozp3p mozsvg mpeg mule mysql nas ncurses neXt nls objc oggvorbis opengl oss pam pdflib perl plotutils png povray python qt quicktime readline ruby samba sasl scanner sdk sdl slang spell sse ssl stencil-buffer svg svga tcltk tcpd tetex tiff truetype truetype-fonts type1-fonts unicode wmf xface xinerama xml xml2 xmms xprint xrandr xv zlib" Unset: ASFLAGS, CBUILD, CTARGET, LC_ALL, LDFLAGS
I don't have any tga images, but this sounds like something that should be filed upstream at http://bugs.gnome.org against nautilus.
Unfortunately I don't have blender to test this with, but I don't see this with "normal" .tga's. Any chance you could supply us with a URL (don't attach) to a problematic .tga? Thanks.
Sorry, for the late response. Here is a problematic TGA file. http://brachttal.net/blender/tmp/windmill.tga
The image is also flipped in gthumb preview, gthumb image view, and in eog image view. Looks like gimp/blender are the only ones that can actually handle it correctly. This should really be reported upstream.
Probably a gdk-pixbuf issue then, I bet gimp does it's own loading routines.
(In reply to comment #5) > Probably a gdk-pixbuf issue then, I bet gimp does it's own loading routines. Still present in GNOME 2.12 (gdk-pixbuf 0.22.0-r3).. should this (bug report) be pushed (opened) upstream?
yes, it probably should
Resolve this bug as UPSTREAM, as the GNOME 2.14 tracker is (erroneously) depending on it.
http://bugzilla.gnome.org/show_bug.cgi?id=105912 fixes the bug upstream.
(In reply to comment #9) > http://bugzilla.gnome.org/show_bug.cgi?id=105912 > fixes the bug upstream. Thanks.
don't resolve if there's a patch available
... Is there any reason this needs to be reopened if it has been fixed upstream in HEAD? Hardly seems worth blocking Gnome 2.14 and maintaining a patch for a MINOR P4 which will probably end up fixed in Gnome 2.14
Block means these are issues that can/should be fixed before putting it in arch, in this case it is obviously easy. #119872 is after all a tracker, a tool, not a judgement system.
... actually, looks like the patch was applied a long time ago upstream. The files in the original patch do display correctly now. I suspect an incomplete fix - partial inspection of TGA header. So. Not in fact corrected completely :)
All I'm saying is this shouldn't be blocking the GNOME 2.14 stabilisation if it's an upstream bug. If there is a working patch available that hasn't been accepted upstream, then fine. But I don't think this is the case. The number 1 priority here is to solve Gentoo distribution problems. This isn't a Gentoo distribution problem. Agreed? Can we at least remove the block?
I agree. Who cares about TGA? This shouldn't block 2.14.
I can't understand why this one was added to the 2.14 tracker at all. This is an old bug. Gnome folks are obviously in no hurry to fix it. It has a very minor impact on a small set of images (not even all TGAs - some orientations work). Someone should triage the tracker list.
I stand by the statement that this bug should not be in the 2.14 tracker block list since it has existed since, well, forever. http://bugzilla.gnome.org/show_bug.cgi?id=347106 I've gone ahead and filed an updated version of the original gnome bug though.
Bug is still there in Gnome 2.18, closing bug as upstream. I've notified them that this is still an issue. Unfortunately, if you really want it fixed, I guess you'll have to dig up gtk+ code [1] to fix yourself. I've pointed out that Gimp doesn't have this issue, you may want to cross reference their TGA loading code too. Thanks [1] http://svn.gnome.org/viewcvs/gtk%2B/trunk/gdk-pixbuf/io-tga.c?view=markup
For reference, bug has been fixed upstream and committed to svn trunk :)