Bug 198377

Summary: f-spot does not work
Product: [openSUSE] openSUSE 10.2 Reporter: Andreas Jaeger <aj>
Component: GNOMEAssignee: Wade Berrier <wberrier>
Status: RESOLVED FIXED QA Contact: E-mail List <qa-bugs>
Severity: Critical    
Priority: P5 - None CC: dmueller, suse-beta
Version: Alpha 3   
Target Milestone: ---   
Hardware: Other   
OS: Other   
Whiteboard:
Found By: Other Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Andreas Jaeger 2006-08-10 05:52:42 UTC 
starting f-spot, I directly get a window with "F-Spot encountered a fatal error".  The contents is:

An unhandled exception was thrown: libgphoto2.so.2

in <0x00048> (wrapper managed-to-native) LibGPhoto2.Context:gp_context_new ()
in <0x0001f> LibGPhoto2.Context:.ctor ()
in <0x0001d> GPhotoCamera:.ctor ()
in <0x003f1> SourceMenu:.ctor (ImportCommand)
in <0x001cc> ImportCommand:ImportFromFile (PhotoStore,string)
in <0x0004a> MainWindow:ImportFile (string)
in <0x0004d> ImportCommand:Execute ()
in <0x00037> (wrapper delegate-invoke) System.MulticastDelegate:invoke_bool ()
in <0x0002a> IdleProxy:Handler ()
in <0x00036> (wrapper native-to-managed) IdleProxy:Handler ()
in (unmanaged) 0xb7eeb080
in <0x00004> (wrapper managed-to-native) Gtk.Application:gtk_main ()
in <0x00007> Gtk.Application:Run ()
in <0x00007> Gnome.Program:Run ()
in <0x005aa> FSpot.Driver:Main (string[])

.NET Version: 1.1.4322.2032

Assembly Version Information:

libgphoto2-sharp (1.0.2411.40252)
FlickrNet (1.1.0.0)
gconf-sharp (2.8.0.0)
pango-sharp (2.8.0.0)
SemWeb (0.5.0.2)
glade-sharp (2.8.0.0)
gtkhtml-sharp (2.8.0.0)
System.Data (1.0.5000.0)
Mono.Data.SqliteClient (1.0.5000.0)
gdk-sharp (2.8.0.0)
gnome-vfs-sharp (2.8.0.0)
dbus-sharp (0.62.0.0)
System (1.0.5000.0)
Mono.Posix (1.0.5000.0)
atk-sharp (2.8.0.0)
gtk-sharp (2.8.0.0)
glib-sharp (2.8.0.0)
gnome-sharp (2.8.0.0)
f-spot (0.0.0.0)
mscorlib (1.0.5000.0)

Platform Information: Linux 2.6.18-rc4-2-default i686 i386 GNU/Linux

Disribution Information:

[/etc/lsb-release]
LSB_VERSION="core-2.0-noarch:core-3.0-noarch:core-2.0-ia32:core-3.0-ia32"

[/etc/SuSE-release]
SUSE Linux 10.1.1 (i586) Alpha3
VERSION = 10.1.1
Comment 1 JP Rosevear 2006-08-10 14:41:31 UTC 
Guessing that libgphoto2 was updated.  Larry will be doing a release shortly in stable
Comment 2 Larry Ewing 2006-09-13 21:32:18 UTC 
Stable has new packages, is this still a problem?
Comment 3 JP Rosevear 2006-09-21 00:57:30 UTC 
Yes, same error in Alpha4.  The issue appears to be that libgphoto2 is not a dep of f-spot and is not installed by default.

CC'ing rudi, I thought that this would be picked up by the autobuild mono deps system.  If not, should be simple to add a libgphoto2 dep.
Comment 4 Ruediger Oertel 2006-09-24 22:25:27 UTC 
I don't see how it should be picked up automatically right now.
f-spot itself _provides_ "mono(libgphoto2-sharp)", so the libgphoto2
mono bindings are provided by f-spot itself.
And there does not seem to be any binary that is linked against libgphoto2
in the f-spot package.

The mono find-provides/requires scripts currently do only find
requires and provides for mono binaries themselves, but not for
these foo.dll.config or foo.exe.config files.

Actually this sounds like a useful extension to /usr/bin/mono-find-requires,
maybe the mono-team can comment on this.
Comment 5 Wade Berrier 2006-09-25 18:08:09 UTC 
It would be neat if mono-find-[provides|requires] also located DllImports as well.

The problem is that the selection process that the runtime uses isn't very simple.  .exe.config files are not required, but can be used to provide a dllmap from the dllname used in the source code to a name or path to a specific library.  The runtime also does some name mangling to try to find a library (prepends lib, tries different extensions of .so, .dll, .dylib, etc...).

The other issue I see is that determining these provides at build time is not always the correct thing to do since the selection is made at runtime.

It would be useful, but I'm not sure it's worth the work to come up with a correct solution.
Comment 6 Wade Berrier 2006-09-25 18:51:34 UTC 
Providing NEEDINFO...
Comment 7 Larry Ewing 2006-09-25 20:14:38 UTC 
added a libgphoto2 dep to the specfile.
Comment 8 JP Rosevear 2006-09-26 15:25:43 UTC 
So fixed for now, re-assigning to rudi for consideration of #4 and #5 with the mono-find-requires script.

Note:  This would catch problems we've had in the past.
Comment 9 Ruediger Oertel 2006-09-26 22:26:14 UTC 
well, I really don't know enough about mono internals to say how much
effort a complete implementation would need.
I could imagine that a tool like "ldd" for binaries would make
sense for mono executables as well ...
from ldd:
# This is the `ldd' command, which lists what shared libraries are
# used by given dynamically-linked executables.  It works by invoking the
# run-time dynamic linker as a command and setting the environment
# variable LD_TRACE_LOADED_OBJECTS to a non-empty value.

not sure if something analog is doable with mono, reassigning to mono
maintainer to decide (or close this bug)
Comment 10 Andreas Hanke 2006-09-27 10:18:15 UTC 
*** Bug 208411 has been marked as a duplicate of this bug. ***
Comment 11 JP Rosevear 2006-09-30 04:48:47 UTC 
*** Bug 147946 has been marked as a duplicate of this bug. ***
Comment 12 Wade Berrier 2006-10-22 22:49:59 UTC 
Turns out Debian's packaging scripts check .config files and some other things that help create most automatic dependencies.  I'll have to try to integrate some of those techniques in mono's rpm find/provides.  But, this is a different bug, so I'll close this one.