Bug 1303286

Well, latest update for eom was from 2015-12-22, so i can't imagine that eom was in your update.
Did it work before the update?
'dnf history' and 'dnf history info <id>' will show you what is updated.
With 'dnf history undo <id>' you can revert a update.

Yes fresh fedora 23 from live image (mate spin) works.  However the next dnf Command was to update fedora to latest so rolling back is unfeasible and it would take me back to orig state

I Rolled back only eom to 1.10.x (which was the version on base fedora 23) but it still has problem - I even created new user (to make sure nothing in overridden settings etc) and same problem.  So now I'm expecting a dependency changed and handling/behaviour is different


To help resolve this, where in the eom code attempts to read the raw file?  Is it in eom specific code or using glib pixbuf etc?  I can try debug locally - I used to be c programmer before I changed path.

Btw, the version from fedora 23 updates repo provided me eom 1.12-1

(In reply to horstsignups from comment #2)
> Yes fresh fedora 23 from live image (mate spin) works.  However the next dnf
> Command was to update fedora to latest so rolling back is unfeasible and it
> would take me back to orig state
> 
> I Rolled back only eom to 1.10.x (which was the version on base fedora 23)
> but it still has problem - I even created new user (to make sure nothing in
> overridden settings etc) and same problem.  So now I'm expecting a
> dependency changed and handling/behaviour is different

Mate 1.12 update was a bit late for f23 release, so i was forced to update during release cycle.
EOM use this relevant build deps:
BuildRequires: libexif-devel
BuildRequires: exempi-devel
BuildRequires: librsvg2-devel
BuildRequires: lcms2-devel
BuildRequires: libjpeg-turbo-devel
but only librsvg2 was updated since f23 release, btw. in january.
Maybe it helps downgrading this package.
> 
> 
> To help resolve this, where in the eom code attempts to read the raw file? 
> Is it in eom specific code or using glib pixbuf etc?  I can try debug
> locally - I used to be c programmer before I changed path.
Good question, can you run EOM with gdb?
A stacktrace should show us where it crashed in code.
Sorry i'm maintaining whole the mate stack and i'm not a specialist for eom.
Btw, can you upload a raw image somewhere, which crashes EOM, for reproducing the issue?

Also, i don't see any relevant commit in git log since 1.10.3.
https://github.com/mate-desktop/eom/commits/1.12

please try this one:
https://www.dropbox.com/s/6rdaxdyqzuq2fwq/20160128_0003.nef.bz2?dl=0

to clarify, eom does not crash/exit when you run "eom foo.nef", its still running but no window is drawn.

HOWEVR, there is something strange I just found:  i have this same NEF fie in a different directory, /export/public, with other files (some jpgs, some txt and some other NEFs)

If I run "eom /export/public/*" then the NEF images ARE displayed!  If I try to "eom /export/public/foo.NEF" then the error line appears


stacktrace:
# in directory /tmp/imgs/ - has .nef and a .jpg
set args *

Breakpoint 1, 0x00007ffff6291400 in gdk_window_create_similar_surface ()
   from /lib64/libgdk-x11-2.0.so.0
(gdb) bt
#0  0x00007ffff6291400 in gdk_window_create_similar_surface ()
    at /lib64/libgdk-x11-2.0.so.0
#1  0x0000555555591f52 in update_pixbuf ()
#2  0x0000555555594e33 in eom_scroll_view_set_image ()
#3  0x000055555557f1b5 in eom_window_display_image ()
#4  0x000055555557fca7 in eom_job_load_cb ()
#5  0x00007ffff2ff19d4 in _g_closure_invoke_va () at /lib64/libgobject-2.0.so.0
#6  0x00007ffff300c2bd in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0
#7  0x00007ffff300c8ff in g_signal_emit () at /lib64/libgobject-2.0.so.0
#8  0x00005555555993fc in notify_finished ()
#9  0x00007ffff2cf2e3a in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
#10 0x00007ffff2cf31d0 in g_main_context_iterate.isra ()
    at /lib64/libglib-2.0.so.0
#11 0x00007ffff2cf34f2 in g_main_loop_run () at /lib64/libglib-2.0.so.0
#12 0x00007ffff664ef37 in gtk_main () at /lib64/libgtk-x11-2.0.so.0
#13 0x0000555555577aa1 in main ()

I'm going to rebuild eom with symbols and see why it fails the assertion on case where I use "*" or explicit set of files, but if I use "." (just the dir), then eom runs showing the jpg but ignoring the nef entirely!

Hmm, here opening the attached file works with both commands and several files in the folder.
I noticed only that thumbnailing in gallerie does not work with that picture format.
[rave@mother ~]$ eom /media/Jackass/Downloads/f22/Test/*
[rave@mother ~]$ eom /media/Jackass/Downloads/f22/Test/20160128_0003.nef 

Btw. i submited a new release today, maybe this helps.
https://bodhi.fedoraproject.org/updates/FEDORA-2016-259a294000

This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.