proper timezone support is still high on my priority list. about your crash, please report a bug
regards s On Sun, 2008-04-27 at 23:41 -0400, Pat Suwalski wrote: > Hello, > > I've brought this issue up before, but now after upgrading to Ubuntu > 8.04 my workaround no longer works. So I'm bringing it up again. > > When one imports photos into f-spot, it modifies the actual photo exif > and changes the time to what the time was at UTC. I worked around this > bad manipulation of exif time by telling f-spot to not write metadata > back to the file. > > The issue, however, is that my displayed date, as well as the date > directory hierarchy where photos are imported to, is still broken, at > least after 19:00 EST. > > My solution to this has always been to run f-spot with: > > TZ=UTC f-spot > > That way the date and directory structure was never mangled. > > However, f-spot now crashes as with the attached log when TZ is modified > thusly. > > I still think it's inappropriate to change the exif date to UTC. It > really does not solve problems regarding date during travels or when > photos are sent from another timezone and imported. > > Can f-spot be made to never modify the time at import? Does anyone have > a more immediate workaround to the problem? > > --Pat > plain text document attachment (f-spot.log) > Stacktrace: > > at FSpot.Global..cctor () <0xffffffff> > at FSpot.Global..cctor () <0x0000d> > at (wrapper runtime-invoke) FSpot.Defines.runtime_invoke_void > (object,intptr,intptr,intptr) <0xffffffff> > at FSpot.Driver.Main (string[]) <0xffffffff> > at FSpot.Driver.Main (string[]) <0x00144> > at (wrapper runtime-invoke) FSpot.Driver.runtime_invoke_int_string[] > (object,intptr,intptr,intptr) <0xffffffff> > > Native stacktrace: > > f-spot [0x51bb67] > f-spot [0x43dacd] > /lib/libpthread.so.0 [0x7f54aceb97d0] > /lib/libc.so.6(memcpy+0x60) [0x7f54ac944d50] > f-spot(mono_breakpoint_clean_code+0x1b) [0x42725b] > f-spot [0x43f78d] > f-spot [0x44005e] > [0x40b4b15b] > > Debug info from gdb: > > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > [Thread debugging using libthread_db enabled] > [New Thread 0x7f54adb997a0 (LWP 14259)] > [New Thread 0x417c6950 (LWP 14261)] > [New Thread 0x40347950 (LWP 14260)] > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > 0x00007f54ac965c4b in fork () from /lib/libc.so.6 > 3 Thread 0x40347950 (LWP 14260) 0x00007f54aceb8e81 in nanosleep () > from /lib/libpthread.so.0 > 2 Thread 0x417c6950 (LWP 14261) 0x00007f54aceb5b99 in > pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 > 1 Thread 0x7f54adb997a0 (LWP 14259) 0x00007f54ac965c4b in fork () > from /lib/libc.so.6 > > Thread 3 (Thread 0x40347950 (LWP 14260)): > #0 0x00007f54aceb8e81 in nanosleep () from /lib/libpthread.so.0 > #1 0x00000000004b8f4f in ?? () > #2 0x00007f54aceb13f7 in start_thread () from /lib/libpthread.so.0 > #3 0x00007f54ac99fb2d in clone () from /lib/libc.so.6 > #4 0x0000000000000000 in ?? () > > Thread 2 (Thread 0x417c6950 (LWP 14261)): > #0 0x00007f54aceb5b99 in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib/libpthread.so.0 > #1 0x00000000004bb585 in ?? () > #2 0x00000000004bdb37 in ?? () > #3 0x00000000004cbc03 in ?? () > #4 0x000000000046b3c1 in ?? () > #5 0x00000000004855c3 in ?? () > #6 0x00000000004cb287 in ?? () > #7 0x00000000004e07d2 in ?? () > #8 0x00007f54aceb13f7 in start_thread () from /lib/libpthread.so.0 > #9 0x00007f54ac99fb2d in clone () from /lib/libc.so.6 > #10 0x0000000000000000 in ?? () > > Thread 1 (Thread 0x7f54adb997a0 (LWP 14259)): > #0 0x00007f54ac965c4b in fork () from /lib/libc.so.6 > #1 0x00007f54ad334d6d in ?? () from /usr/lib/libglib-2.0.so.0 > #2 0x00007f54ad3358df in g_spawn_sync () from /usr/lib/libglib-2.0.so.0 > #3 0x00007f54ad335d98 in g_spawn_command_line_sync () > from /usr/lib/libglib-2.0.so.0 > #4 0x000000000051bbf9 in ?? () > #5 0x000000000043dacd in ?? () > #6 <signal handler called> > #7 0x00007f54ac944d50 in memcpy () from /lib/libc.so.6 > #8 0x000000000042725b in mono_breakpoint_clean_code () > #9 0x000000000043f78d in ?? () > #10 0x000000000044005e in ?? () > #11 0x0000000040b4b15b in ?? () > #12 0x0000000000000000 in ?? () > #0 0x00007f54ac965c4b in fork () from /lib/libc.so.6 > > > ================================================================= > Got a SIGSEGV while executing native code. This usually indicates > a fatal error in the mono runtime or one of the native libraries > used by your application. > ================================================================= > > _______________________________________________ > F-spot-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/f-spot-list _______________________________________________ F-spot-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/f-spot-list
