On Wed, 2012-05-23 at 11:04 -0400, Jack wrote: > I've been using f-spot for quite a while, with about 3500 photos. I'm > on Gentoo Linux, and a recent set of updates left f-spot not working. > One of the libraries it uses got updated, but not f-spot itself, and > the error on startup included "f-spot caught an exception - > hyena.data.sqlite.sqliteexception: sqlite error 1: no such table: > tags". I doubt this is due to a library update. It sounds like a straight forward database problem. Why do you think "no such table: tags" does not accurately describe the problem? If you look at the F-Spot sqlite database does it have a tags table? $ sqlite3 $HOME/.config/f-spot/photos.db sqlite> .schema CREATE TABLE tags ( id INTEGER PRIMARY KEY NOT NULL, name TEXT UNIQUE, category_id INTEGER, is_category BOOLEAN, sort_priority INTEGER, icon TEXT ); > I assumed that once I got all the other updates done, and I > recompiled f-spot, it would work again. (The only reason I have that > error message is that I extracted it from the google search in my > browser history.) Eh? I have no idea what this means. > Well, after all the recompiling, my next attempt to > run f-spot said something about a bad database. Unfortunately, EVERY > f-spot .db file I could find (scattered in several directories, > probably due to some attempts at command line start) were empty except > for a meta table. The only f-spot backup .db files were from 2009. I don't believe there is a relevant database anywhere other than $HOME/.config/f-spot/ Perhaps you have very old database lying about as a result of the location being moved over time and a real migration having not occurred. > I know it's my own fault for not having a recent backup, but I'm really > surprised that f-spot would overwrite the database unless it started > successfully and had something to change. Is there potential here for > an enhancement request that a backup is made of the .db file before any > attempt to open it? I dunno; photos.db can be pretty big. I personally don't see a need for this. (a) Users should make backups. (b) Developers [you are compiling - THIS MEAN YOU!] take full responsibility for what they are doing. Developers certainly know enough to make backups; otherwise they shouldn't be playing with those toys. Better yet, IMNSHO, do not use Gentoo. Use a distribution that has a QC workflow and builds packages in a consistent manner. > At this point I'm really just looking to > understand when/why/how the .db got overwritten, as well as seeing if > f-spot can avoid such problems in the future - even if the problem is > actually in one of the libraries and not f-spot itself. I have a hard time believing F-Spot overwrote your database. I'd suspect your build got screwed up, F-Spot couldn't open the database, and you did 'something' to make it work. That 'something' deleted your database. > Thanks for any relevant information, suggestions, or advice (other than > to do more backups). :) Make more backups!
Attachment:
signature.asc
Description: This is a digitally signed message part