Bug 500758 - cannot add hamster-applet to GNOME panel
cannot add hamster-applet to GNOME panel
Product: Fedora
Classification: Fedora
Component: hamster-applet (Show other bugs)
All Linux
high Severity high
: ---
: ---
Assigned To: Mads Villadsen
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-05-13 20:54 EDT by James Ralston
Modified: 2009-12-01 12:27 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-12-01 12:27:48 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description James Ralston 2009-05-13 20:54:27 EDT
I'm running Fedora 11 Preview (updated to latest Rawhide), and I cannot add the Hamster applet to my GNOME panel.

Hamster appears on the "Find an item to add to the panel" list as:

    Time Tracker
    Project Hamster - track your time

But when I select it and click "Add", a pop-up panel appears that says:

    The panel encountered a problem
    while loading "OAFIID:Hamster_Applet".

    Do you want to delete the applet from your configuration?

I can't find any other error messages.

I had no problems with Hamster on Fedora 10.


Comment 1 Mads Villadsen 2009-05-14 17:01:20 EDT
Could you try running the following command from a terminal and posting the output here?

/usr/lib64/hamster-applet/hamster-applet -w -t
Comment 2 James Ralston 2009-05-14 19:33:43 EDT
Aha; that was useful:

Data Dir: /usr/share/hamster-applet
SELECT version FROM version None
ALTER TABLE facts add column description varchar2 ()
Traceback (most recent call last):
  File "/usr/lib64/hamster-applet/hamster-applet", line 60, in <module>
  File "/usr/lib64/python2.6/site-packages/hamster/__init__.py", line 90, in __init_db
    storage = Storage(dispatcher)
  File "/usr/lib64/python2.6/site-packages/hamster/storage.py", line 26, in __init__
  File "/usr/lib64/python2.6/site-packages/hamster/db.py", line 689, in run_fixtures
    self.execute("ALTER TABLE facts add column description varchar2")
  File "/usr/lib64/python2.6/site-packages/hamster/db.py", line 506, in execute
    res = cur.execute(statement, params)
sqlite3.OperationalError: duplicate column name: description

From digging in /usr/lib64/python2.5/site-packages/hamster/db.py, I see the problem: hamster-applet 2.24.2 (on Fedora 10) has this code:

        #lock down current version
        self.execute("UPDATE version SET version = 4")

While hamster-applet 2.26.0 does this:

        # at the happy end, update version number
        if version < current_version:
            #lock down current version
            self.execute("UPDATE version SET version = %d" % current_version)

I rsync ~/.gnome2/hamster-applet among the various boxes I use. When I rsync'ed the version 5 db from my Fedora 11 Preview box back to my Fedora 10 box, when I next ran hamster-applet on my Fedora 10 box, it "upgraded" the version number of the db from 5 to 4. While that didn't cause any problems for 2.24.2, when I rsync'ed that db back to my Fedora 11 Preview box, the next time hamster-applet ran, it thought the database was out of date, and attempted to update it, which failed because it was actually a version 5 database mislabeled as version 4.

For now, as a work-around, I'll just reset the db version number manually after 2.24.2 rewinds it to 4.

I can think of at least two different ways to fix this:

1. Release hamster-applet-2.26.0 for Fedora 9/10.

2. Patch 2.24.2 to use the "if version < current_version" check.

I'd vote for option #1, as 2.26.0 squashes the annoying "garbage date in date field on 64-bit machines" bug:

Comment 3 Bug Zapper 2009-06-09 11:48:03 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
Comment 4 James Ralston 2009-12-01 12:27:48 EST
Closing, as Fedora 10 is about to go EOL, and F11 (and later) don't have this problem.

Note You need to log in before you can comment on or make changes to this bug.