abrt 1.0.9 detected a crash. architecture: x86_64 cmdline: python /usr/lib64/timer-applet/timer-applet --oaf-activate-iid=OAFIID:TimerApplet_Factory --oaf-ior-fd=30 comment: Timer-applet producing backtrace at session start component: gnome-applet-timer executable: /usr/lib64/timer-applet/timer-applet kernel: 2.6.33.1-24.fc13.x86_64 package: gnome-applet-timer-2.1.2-6.fc13 reason: gettext.py:131:_expand_lang:ImportError: No module named gi release: Fedora release 13 (Goddard) backtrace ----- gettext.py:131:_expand_lang:ImportError: No module named gi Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/timerapplet/core/AppletGConfWrapper.py", line 85, in _notification_callback callback(gconf_value, real_data) File "/usr/lib/python2.6/site-packages/timerapplet/controllers/TimerApplet.py", line 325, in _on_gconf_changed self._update_status_button() File "/usr/lib/python2.6/site-packages/timerapplet/controllers/TimerApplet.py", line 192, in _update_status_button self._status_button.set_tooltip(_('Click to start a new timer countdown.')) File "/usr/lib64/python2.6/gettext.py", line 568, in gettext return dgettext(_current_domain, message) File "/usr/lib64/python2.6/gettext.py", line 532, in dgettext codeset=_localecodesets.get(domain)) File "/usr/lib64/python2.6/gettext.py", line 467, in translation mofiles = find(domain, localedir, languages, all=1) File "/usr/lib64/python2.6/gettext.py", line 439, in find for nelang in _expand_lang(lang): File "/usr/lib64/python2.6/gettext.py", line 131, in _expand_lang from locale import normalize ImportError: No module named gi Local variables in innermost frame: locale: 'en_US.UTF-8' How to reproduce ----- 1. Start standard GNOME session, with timer-applet in the panel as a default app. 2. Backtrace at startup. 3. Applet continues running without apparent difficulty
Created attachment 406380 [details] File: backtrace
Hi Paul, this is a really nice issue. It seems this bug appears now at least twice and on 2 independent machines in the same module "gettext", which nobody can explain atm... Also: Local variables in innermost frame: locale: 'en_US.UTF-8' is the same. But this should not be the problem too... *** This bug has been marked as a duplicate of bug 569885 ***