Re: The timestamp thing
On Sat, 2009-11-07 at 09:49 -0500, Brian J. Murrell wrote: > How are you using patch? You must give the patch to patch on stdin, not > as a command line argument: > > $ patch ... < file.patch > > NOT > > $patch ... file.patch > > The latter would definitely cause your symptoms. Ooh, facepalm. It's obviously been a while since I've had to patch anything. Thanks for the reminder. It works now. > > There's one thing I'd point out for those of you circumventing f-spot's > UTC manipulation and that's that when this mess is finally, officially, > fixed, I'd hope to hell that part of the fix is for f-spot to go "fix" > all of the manipulations it has done, or at least account for them, > somehow in it's corrections. > > That will meant that those of you that have been circumventing and/or > undoing the UTC normalization will have your timestamps warped once > again, in the opposite direction, unless f-spot, somehow allows for the > fact that some people have been manipulating timestamp in a way other > than f-spot expects. That is indeed a problem, and one that I've been expecting to run into. I imagine most people will simply have to use F-Spot's own "Adjust Time" to correct their whole library by the difference between localtime and UTC wherever they are. I know that's what I've had to do on every import ever since I enabled writing metadata to files. I definitely wouldn't use this patch without understanding the consequences when this issue is finally fixed properly. I think the most important thing to do to prepare for an eventual official fix is to ensure that timestamps in the files are all consistent. I could foresee problems if someone where to import half their photos without "Write Metadata" and the other half with, for example. Regards, -- Steve McGrath [email protected] signature.asc Description: This is a digitally signed message part ___ F-spot-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/f-spot-list
Re: The timestamp thing
On Sat, Nov 7, 2009 at 3:49 PM, Brian J. Murrell wrote: [...] > > There's one thing I'd point out for those of you circumventing f-spot's > UTC manipulation and that's that when this mess is finally, officially, > fixed, I'd hope to hell that part of the fix is for f-spot to go "fix" > all of the manipulations it has done, or at least account for them, > somehow in it's corrections. > > That will meant that those of you that have been circumventing and/or > undoing the UTC normalization will have your timestamps warped once > again, in the opposite direction, unless f-spot, somehow allows for the > fact that some people have been manipulating timestamp in a way other > than f-spot expects. f-spot has a "adjust time" dialog, which allows manual changes to the timestamps. I'm not sure it is possible to pull appart changes applied automatically and manual ones, except maybe that automaticall changes are always for an exact number of hours. Regards. -- Aurélien Naldi ___ F-spot-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/f-spot-list
Re: The timestamp thing
On Sat, 2009-11-07 at 08:37 -0600, Steve McGrath wrote: > Whenever I try to apply it, patch > simply hangs forever with no output... It's very strange. How are you using patch? You must give the patch to patch on stdin, not as a command line argument: $ patch ... < file.patch NOT $patch ... file.patch The latter would definitely cause your symptoms. There's one thing I'd point out for those of you circumventing f-spot's UTC manipulation and that's that when this mess is finally, officially, fixed, I'd hope to hell that part of the fix is for f-spot to go "fix" all of the manipulations it has done, or at least account for them, somehow in it's corrections. That will meant that those of you that have been circumventing and/or undoing the UTC normalization will have your timestamps warped once again, in the opposite direction, unless f-spot, somehow allows for the fact that some people have been manipulating timestamp in a way other than f-spot expects. b. signature.asc Description: This is a digitally signed message part ___ F-spot-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/f-spot-list
Re: The timestamp thing
On Sat, 2009-11-07 at 08:37 -0600, Steve McGrath wrote:
> I've been attempting to make a patch based on the differences between
> your branch and the latest F-Spot sources from git. I'm not having much
> luck, though. I've not a whole lot of experience in this area.
>
> Is there any chance you could take a look at this patch file and help me
> figure out what I've done wrong? Whenever I try to apply it, patch
> simply hangs forever with no output... It's very strange.
And... Here's the patch. Man, I hate when I do that.
diff -Naur f-spot/src/Imaging/Ciff.cs paulwbs-clone/src/Imaging/Ciff.cs
--- f-spot/src/Imaging/Ciff.cs 2009-11-07 02:40:43.111028831 -0600
+++ paulwbs-clone/src/Imaging/Ciff.cs 2009-11-07 02:20:06.939030168 -0600
@@ -441,7 +441,7 @@
return base.Date;
}
-return new CaptureTime (date, little).LocalTime.ToUniversalTime ();
+return new CaptureTime (date, little).LocalTime;
}
}
diff -Naur f-spot/src/Imaging/ImageFile.cs paulwbs-clone/src/Imaging/ImageFile.cs
--- f-spot/src/Imaging/ImageFile.cs 2009-11-07 02:04:39.171029348 -0600
+++ paulwbs-clone/src/Imaging/ImageFile.cs 2009-11-07 01:17:46.695030565 -0600
@@ -206,7 +206,7 @@
return t;
}
-
+
[Obsolete ("use Create (System.Uri) instead")]
public static ImageFile Create (string path)
{
diff -Naur f-spot/src/Imaging/JpegFile.cs paulwbs-clone/src/Imaging/JpegFile.cs
--- f-spot/src/Imaging/JpegFile.cs 2009-11-07 02:40:43.111028831 -0600
+++ paulwbs-clone/src/Imaging/JpegFile.cs 2009-11-07 02:21:18.227040590 -0600
@@ -333,13 +333,13 @@
e = sub.Directory [0].Lookup (TagId.DateTimeOriginal);
if (e != null)
- return DirectoryEntry.DateTimeFromString (e.StringValue).ToUniversalTime ();
+ return DirectoryEntry.DateTimeFromString (e.StringValue);
}
e = ExifHeader.Directory.Lookup (TagId.DateTime);
if (e != null)
- return DirectoryEntry.DateTimeFromString (e.StringValue).ToUniversalTime ();
+ return DirectoryEntry.DateTimeFromString (e.StringValue);
return base.Date;
#else
@@ -349,7 +349,7 @@
if (time_str == null || time_str == "")
time_str = ExifData.LookupFirstValue (Exif.Tag.DateTime);
- time = Exif.ExifUtil.DateTimeFromString (time_str).ToUniversalTime ();
+ time = Exif.ExifUtil.DateTimeFromString (time_str);
#endif
} catch (System.Exception e) {
Console.WriteLine (e);
diff -Naur f-spot/src/Imaging/MrwFile.cs paulwbs-clone/src/Imaging/MrwFile.cs
--- f-spot/src/Imaging/MrwFile.cs 2009-11-07 02:40:43.111028831 -0600
+++ paulwbs-clone/src/Imaging/MrwFile.cs 2009-11-07 01:17:46.695030565 -0600
@@ -201,7 +201,7 @@
DirectoryEntry e = this.Header.Directory.Lookup (TagId.DateTime);
if (e != null)
- return DirectoryEntry.DateTimeFromString (e.StringValue).ToUniversalTime ();
+ return DirectoryEntry.DateTimeFromString (e.StringValue);
else
return base.Date;
}
diff -Naur f-spot/src/Imaging/PngFile.cs paulwbs-clone/src/Imaging/PngFile.cs
--- f-spot/src/Imaging/PngFile.cs 2009-11-07 02:40:43.115031295 -0600
+++ paulwbs-clone/src/Imaging/PngFile.cs 2009-11-07 02:22:00.327037656 -0600
@@ -1418,7 +1418,7 @@
foreach (Chunk chunk in Chunks) {
TimeChunk time = chunk as TimeChunk;
if (time != null)
- return time.Time.ToUniversalTime ();
+ return time.Time;
}
return base.Date;
}
diff -Naur f-spot/src/Imaging/Tiff.cs paulwbs-clone/src/Imaging/Tiff.cs
--- f-spot/src/Imaging/Tiff.cs 2009-11-07 02:40:43.115031295 -0600
+++ paulwbs-clone/src/Imaging/Tiff.cs 2009-11-07 01:17:46.711030015 -0600
@@ -2066,13 +2066,13 @@
e = sub.Directory [0].Lookup (TagId.DateTimeOriginal);
if (e != null)
- return DirectoryEntry.DateTimeFromString (e.StringValue).ToUniversalTime ();
+ return DirectoryEntry.DateTimeFromString (e.StringValue);
}
e = this.Header.Directory.Lookup (TagId.DateTime);
if (e != null)
- return DirectoryEntry.DateTimeFromString (e.StringValue).ToUniversalTime ();
+ return DirectoryEntry.DateTimeFromString (e.StringValue);
else
return base.Date;
}
diff -Naur f-spot/src/Jobs/SyncMetadataJob.cs paulwbs-clone/src/Jobs/SyncMetadataJob.cs
--- f-spot/src/Jobs/SyncMetadataJob.cs 2009-11-07 02:40:43.115031295 -0600
+++ paulwbs-clone/src/Jobs/SyncMetadataJob.cs 2009-11-07 01:17:46.711030015 -0600
@@ -53,7 +53,7 @@
FSpot.JpegFile jimg = img as FSpot.JpegFile;
jimg.SetDescription (photo.Description);
- jimg.SetDateTimeOriginal (photo.Time.ToLocalTime ());
+ jimg.SetDateTimeOriginal (photo.Time);
jimg.SetXmp (UpdateXmp (photo, jimg.Header.GetXmp ()));
jimg.SaveMetaData (path);
diff -Naur f-spot/src/UI.Dialog/AdjustTimeDialog.cs paulwbs-clone/src/UI.Dialog/AdjustTimeDialog.cs
--- f-spot/src/UI.Dialog/AdjustTimeDialog.cs 2009-11-07 02:40:43.119030616 -0600
+++ paulwbs-clone/src/UI.Dialog/AdjustTimeDialog.cs 2009-11-07
Re: The timestamp thing
On Fri, 2009-11-06 at 15:49 +0100, Paul Wellner Bou wrote: > Done. > http://gitorious.org/~paulwb/f-spot/paulwbs-clone/commits/ImportTimeHandling > > git clone git://gitorious.org/~paulwb/f-spot/paulwbs-clone.git > cd paulwbs-clone/ > git checkout origin/ImportTimeHandling > ./autogen.sh > make && sudo make install > > Stephane's latest unique-sharp stuff is in there, you'll need > libunique-dev installed (or however this is called on your distribution). > > Regards > Paul. I've been attempting to make a patch based on the differences between your branch and the latest F-Spot sources from git. I'm not having much luck, though. I've not a whole lot of experience in this area. Is there any chance you could take a look at this patch file and help me figure out what I've done wrong? Whenever I try to apply it, patch simply hangs forever with no output... It's very strange. Regards, -- Steve McGrath [email protected] signature.asc Description: This is a digitally signed message part ___ F-spot-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/f-spot-list
Re: The timestamp thing
Hate to say this, but I also agree... am getting closer and closer to move to Digikam because of this one... Just hoping Digikam will import all tags correctly... And that F-Spot will import digikam's tags later on (perhaps) Silvano wrote: > Dotan, the situation that you describes match 100% mine :-) > > Silvano > > On Thu, Nov 5, 2009 at 08:16, Dotan Cohen wrote: >>> That said, this ongoing timestamp issue is driving me nuts. I recently >>> had to fix the timestamps on about 2,000 photos, some of which had been >>> previously adjusted due to my camera being set wrong for a while. This >>> caused much badness, completely hosed all my timestamps, and brought >>> about the wailing and the gnashing of teeth. >>> >>> >> While testing F-Spot and Digikam some time back, I was bit by this >> issue twice. Although F-Spot has the cleaner interface and the >> versioning feature that we love, I am waiting for this issue to be >> resolved before moving back to F-Spot. In fact, that is the reason >> that I am still subscribed to this list. >> >> >> -- >> Dotan Cohen >> >> http://what-is-what.com >> http://gibberish.co.il >> ___ >> 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
Re: The timestamp thing
On Wed, 2009-11-04 at 15:36 -0800, Michael Lissner wrote: > Call me naive, but why is it that the timestamps are automatically > altered at all? I'd expect them not to be altered at all, unless I use > the "Adjust time" tool. As far as I know, no other photo program does > anything like this. Adobe Lightroom, Picasa, digiKam, etc, don't do > anything like this, even as a feature, right? > > I'm confused why anybody would even want the option to do this. > > Michael Lissner > [email protected] > 909-576-4123 That's basically my point exactly, the only reason I mention having the option is because the developers seem to think there's a use case that requires it. Therefore I am suggesting that a compromise should be made, that of making this "Feature" optional. Regards, -- Steve McGrath [email protected] signature.asc Description: This is a digitally signed message part ___ F-spot-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/f-spot-list
Re: The timestamp thing
Call me naive, but why is it that the timestamps are automatically altered at all? I'd expect them not to be altered at all, unless I use the "Adjust time" tool. As far as I know, no other photo program does anything like this. Adobe Lightroom, Picasa, digiKam, etc, don't do anything like this, even as a feature, right? I'm confused why anybody would even want the /option/ to do this. Michael Lissner [email protected] 909-576-4123 Steve McGrath wrote on 11/04/2009 02:57 PM: > On Wed, 2009-11-04 at 23:26 +0100, Silvano wrote: > >> It's obvious to me that the F-Spot maintainers are more interested on >> fancy features (rolls support, extensions, rating...) than on fixing >> this hated feature (because unexpected, because undocumented...). >> >> In my opinion, that's for them a desired feature (if not, they would >> have never bothered to implement it) and therefore no urgent fix is >> required. They probably think, that documenting is a nice to have... >> >> I hope that you have luck and this feature gets fixed some day. I even >> offered once to fix it, but one of the maintainers told me that it was >> in his plans doing it. Repeating requests for that might convince them >> to fix it :-) >> >> Regards, >> Silvano >> >> > From my (admittedly limited) understanding, the developers are still > trying to figure out the best way of handling timestamp modification. > > My proposed solution for the time being would be to simply offer users a > choice, even it's buried in GConf, as to whether F-Spot should modify > timestamps or leave them alone. This should be alongside the option of > having F-Spot not touch metadata at all, and store tags and such only in > the DB. > > Having not looked at the codebase myself, I don't know what the > underlying problems are that have kept this issue open for over 3 years, > but frankly, something needs to be done. > > Ubuntu, which includes F-Spot as it's default photo-manager, has this > issue marked as a high importance bug. Some people have even been > pushing for F-Spot to be removed from the default Ubuntu install until > the issue is resolved. I don't want to see that happen; I'd rather that > Ubuntu ship a version of F-Spot patched to leave timestamps alone, at > least as a stopgap measure until this is dealt with in F-Spot. > > The Ubuntu bug is > https://bugs.launchpad.net/ubuntu/+source/f-spot/+bug/175191 > > Regards, > > > > > > ___ > 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
Re: The timestamp thing
On Wed, 2009-11-04 at 23:26 +0100, Silvano wrote: > It's obvious to me that the F-Spot maintainers are more interested on > fancy features (rolls support, extensions, rating...) than on fixing > this hated feature (because unexpected, because undocumented...). > > In my opinion, that's for them a desired feature (if not, they would > have never bothered to implement it) and therefore no urgent fix is > required. They probably think, that documenting is a nice to have... > > I hope that you have luck and this feature gets fixed some day. I even > offered once to fix it, but one of the maintainers told me that it was > in his plans doing it. Repeating requests for that might convince them > to fix it :-) > > Regards, > Silvano > From my (admittedly limited) understanding, the developers are still trying to figure out the best way of handling timestamp modification. My proposed solution for the time being would be to simply offer users a choice, even it's buried in GConf, as to whether F-Spot should modify timestamps or leave them alone. This should be alongside the option of having F-Spot not touch metadata at all, and store tags and such only in the DB. Having not looked at the codebase myself, I don't know what the underlying problems are that have kept this issue open for over 3 years, but frankly, something needs to be done. Ubuntu, which includes F-Spot as it's default photo-manager, has this issue marked as a high importance bug. Some people have even been pushing for F-Spot to be removed from the default Ubuntu install until the issue is resolved. I don't want to see that happen; I'd rather that Ubuntu ship a version of F-Spot patched to leave timestamps alone, at least as a stopgap measure until this is dealt with in F-Spot. The Ubuntu bug is https://bugs.launchpad.net/ubuntu/+source/f-spot/+bug/175191 Regards, -- Steve McGrath [email protected] signature.asc Description: This is a digitally signed message part ___ F-spot-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/f-spot-list
Re: The timestamp thing
It's obvious to me that the F-Spot maintainers are more interested on fancy features (rolls support, extensions, rating...) than on fixing this hated feature (because unexpected, because undocumented...). In my opinion, that's for them a desired feature (if not, they would have never bothered to implement it) and therefore no urgent fix is required. They probably think, that documenting is a nice to have... I hope that you have luck and this feature gets fixed some day. I even offered once to fix it, but one of the maintainers told me that it was in his plans doing it. Repeating requests for that might convince them to fix it :-) Regards, Silvano On Wed, Nov 4, 2009 at 22:21, Michael Lissner wrote: > I'm not an f-spot developer, but I can say that this problem REALLY needs to > be elevated, as exemplified by the LWN posting a couple weeks ago. > > I have lost many, many hours to fixing, adjusting and manipulating time > stamps as a result of whatever it is that f-spot does. I assume developers > are aware of this problem now, so I guess the question is, what do we need > to do to get it on the road map, and to get it fixed? > > Michael Lissner > [email protected] > 909-576-4123 > > Steve McGrath wrote on 11/04/2009 12:05 PM: > > Hi all, > Let me first say that F-Spot has absolutely rocked for me for a few > years now, and I won't use anything else. > > That said, this ongoing timestamp issue is driving me nuts. I recently > had to fix the timestamps on about 2,000 photos, some of which had been > previously adjusted due to my camera being set wrong for a while. This > caused much badness, completely hosed all my timestamps, and brought > about the wailing and the gnashing of teeth. > > I've cleaned that mess up now, all my timestamps are as correct as > they're ever going to be. And now I'd like to keep them that way. What's > the best way to accomplish this? > > I understand that F-Spot doesn't touch the timestamps if not set to > store metadata in the files; but I'd still like to be able to save tags > and captions into the files to work with other software. > > I suppose my two main questions boil down to these: > I understand that if I start F-Spot with TZ=UTC set, it won't alter > timestamps on new imports. Does it do anything to the way F-Spot > displays timestamps from already-imported photos? > > Also, I've heard of a couple patches for F-Spot which keep it from > mucking about with my EXIF timestamps. Is there such a patch which is > compatible with the latest version? > > > > ___ > 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 > > -- “Imagine que no hubiera situaciones hipotéticas” John Mendoza "Imagine there weren't any hypothetical situations" John Mendoza ___ F-spot-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/f-spot-list
Re: The timestamp thing
I'm not an f-spot developer, but I can say that this problem REALLY needs to be elevated, as exemplified by the LWN posting a couple weeks ago. I have lost many, many hours to fixing, adjusting and manipulating time stamps as a result of whatever it is that f-spot does. I assume developers are aware of this problem now, so I guess the question is, what do we need to do to get it on the road map, and to get it fixed? Michael Lissner [email protected] 909-576-4123 Steve McGrath wrote on 11/04/2009 12:05 PM: > Hi all, > Let me first say that F-Spot has absolutely rocked for me for a few > years now, and I won't use anything else. > > That said, this ongoing timestamp issue is driving me nuts. I recently > had to fix the timestamps on about 2,000 photos, some of which had been > previously adjusted due to my camera being set wrong for a while. This > caused much badness, completely hosed all my timestamps, and brought > about the wailing and the gnashing of teeth. > > I've cleaned that mess up now, all my timestamps are as correct as > they're ever going to be. And now I'd like to keep them that way. What's > the best way to accomplish this? > > I understand that F-Spot doesn't touch the timestamps if not set to > store metadata in the files; but I'd still like to be able to save tags > and captions into the files to work with other software. > > I suppose my two main questions boil down to these: > I understand that if I start F-Spot with TZ=UTC set, it won't alter > timestamps on new imports. Does it do anything to the way F-Spot > displays timestamps from already-imported photos? > > Also, I've heard of a couple patches for F-Spot which keep it from > mucking about with my EXIF timestamps. Is there such a patch which is > compatible with the latest version? > > > > > ___ > 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
Re: The timestamp thing
On Wed, 2009-11-04 at 21:34 +0100, Aurélien Naldi wrote: > A while ago, I had a look at a branch for this. The patch was pretty > straightforward: remove all calls to the function responsible with > timestamp shifts. > If this branch has not yet been ported to the latest version, I hope > it is still simple enough to do it again. I may look at the existing patch myself, if it's fairly straightforward perhaps I can make some progress, although I'm not a C# coder, and barely even a C coder ;) > While someone else raise this concern again, I would like to re-ask > wether there is a chance for upstream f-spot to make it easier for the > people willing to keep their timestamps sane without loosing tags. > > A simple function, performing or not the timestamp shift depending on > an hidden gconf key would for example be lovely. It would be even > better if it could depend on the status of a checkbox in the import > dialog. I'd like this implemented as well. > Indeed, even if the current behaviour is a feature, it can not > possibly be right to shift timestamps each time a picture is imported > (I happened to drop my f-spot DB several times to test tag imports and > other new features in the past...) I've heard it argued that since you check the "Store metadata in the file" box, you're indicating that you want F-Spot to alter your metadata. However, my take on this is that a distinction should be made here: My intention, in telling F-Spot to store metadata in the files, is something along the lines of "Yes, please store the changes *I make* to the metadata (tags, *Manually adjusted* timestamps, etc) into the files. It was never my intention, as a user, to have F-Spot *automatically* adjust any metadata. I very much think that a separate and distinct permission should be granted for F-Spot to automatically adjust timestamps. I'm not sure how the developers feel on the issue, but to me it seems quite clear that there is a difference between writing user-initiated changes to the files, and automatically altering the files. > If such a patch has a chance to be accepted, I am willing to help with > the code, unless a better solution is in the work? > > Best regards. > Thanks for your input on this. It doesn't directly answer my questions, but it does bring up some good points. Regards, -- Steve McGrath [email protected] signature.asc Description: This is a digitally signed message part ___ F-spot-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/f-spot-list
Re: The timestamp thing
On Wed, Nov 4, 2009 at 9:05 PM, Steve McGrath wrote: > Hi all, > Let me first say that F-Spot has absolutely rocked for me for a few > years now, and I won't use anything else. Hi, I have to say I also love f-spot :) > That said, this ongoing timestamp issue is driving me nuts. I recently > had to fix the timestamps on about 2,000 photos, some of which had been > previously adjusted due to my camera being set wrong for a while. This > caused much badness, completely hosed all my timestamps, and brought > about the wailing and the gnashing of teeth. > [...] > > Also, I've heard of a couple patches for F-Spot which keep it from > mucking about with my EXIF timestamps. Is there such a patch which is > compatible with the latest version? A while ago, I had a look at a branch for this. The patch was pretty straightforward: remove all calls to the function responsible with timestamp shifts. If this branch has not yet been ported to the latest version, I hope it is still simple enough to do it again. While someone else raise this concern again, I would like to re-ask wether there is a chance for upstream f-spot to make it easier for the people willing to keep their timestamps sane without loosing tags. A simple function, performing or not the timestamp shift depending on an hidden gconf key would for example be lovely. It would be even better if it could depend on the status of a checkbox in the import dialog. Indeed, even if the current behaviour is a feature, it can not possibly be right to shift timestamps each time a picture is imported (I happened to drop my f-spot DB several times to test tag imports and other new features in the past...) If such a patch has a chance to be accepted, I am willing to help with the code, unless a better solution is in the work? Best regards. -- Aurélien Naldi ___ F-spot-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/f-spot-list
