Bug 569885 - "ImportError: No module named gi" seen importing modules apparently unrelated to "gi"
"ImportError: No module named gi" seen importing modules apparently unrelated...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: gnome-python2 (Show other bugs)
rawhide
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Colin Walters
Fedora Extras Quality Assurance
abrt_hash:d99f20be
: Reopened
: 576587 577276 582047 588465 (view as bug list)
Depends On:
Blocks: F13Blocker/F13FinalBlocker
  Show dependency treegraph
 
Reported: 2010-03-02 11:25 EST by Baris Cicek
Modified: 2010-05-06 03:03 EDT (History)
14 users (show)

See Also:
Fixed In Version: pygobject2-2.21.1-6.fc13
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-05-06 03:03:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
File: backtrace (1.19 KB, text/plain)
2010-03-02 11:25 EST, Baris Cicek
no flags Details
clear error (929 bytes, patch)
2010-05-05 14:06 EDT, Colin Walters
walters: review?
Details | Diff

  None (edit)
Description Baris Cicek 2010-03-02 11:25:16 EST
abrt 1.0.8 detected a crash.

architecture: x86_64
cmdline: python /usr/lib64/timer-applet/timer-applet --oaf-activate-iid=OAFIID:TimerApplet_Factory --oaf-ior-fd=28
component: gnome-applet-timer
executable: /usr/lib64/timer-applet/timer-applet
kernel: 2.6.33-0.48.rc8.git1.fc14.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 14 (Rawhide)

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'
Comment 1 Baris Cicek 2010-03-02 11:25:19 EST
Created attachment 397360 [details]
File: backtrace
Comment 2 Thomas Spura 2010-03-02 11:51:56 EST
Thanks for the bug report.

The backtrace looks pretty strange. There is an ImportError, but there is no 'import gi'...

Reassigning to python, because this import should be somewhere in locale.py or gettext.py, (if ever, as already said, I didn't find it...).


Does this happen everytime?
Which version of python do you have?
Comment 3 Dave Malcolm 2010-03-03 14:59:00 EST
Thanks for filing this bug report.

How reproducible is this problem?

What is the output of running these commands?
  ls -al /usr/lib64/python2.6/site-packages/*gi*
  rpm -qf /usr/lib64/python2.6/site-packages/*gi*

Thanks!

(the report is rather unusual; I'm not sure what "gi" is doing there.  I wonder if it's something to do with http://live.gnome.org/PyGI )
Comment 4 Baris Cicek 2010-03-03 15:18:23 EST
I don't know how producable this bug is, but info you wanted is as following:
[xxx@alanine pear]$ ls -al /usr/lib64/python2.6/site-packages/*gi*
total 772
drwxr-xr-x  2 root root  4096 Jan 30 16:03 .
drwxr-xr-x 53 root root 12288 Mar  3 21:15 ..
-rw-r--r--  1 root root 30165 Jan 28 23:15 annotationparser.py
-rw-r--r--  1 root root 28082 Jan 28 23:15 annotationparser.pyc
-rw-r--r--  1 root root 27911 Jan 28 23:15 annotationparser.pyo
-rw-r--r--  1 root root 15216 Jan 28 23:15 ast.py
-rw-r--r--  2 root root 20333 Jan 28 23:15 ast.pyc
-rw-r--r--  2 root root 20333 Jan 28 23:15 ast.pyo
-rw-r--r--  1 root root  4300 Jan 28 23:15 cachestore.py
-rw-r--r--  2 root root  3371 Jan 28 23:15 cachestore.pyc
-rw-r--r--  2 root root  3371 Jan 28 23:15 cachestore.pyo
-rw-r--r--  1 root root   978 Jan 28 23:15 config.py
-rw-r--r--  2 root root   294 Jan 28 23:15 config.pyc
-rw-r--r--  2 root root   294 Jan 28 23:15 config.pyo
-rw-r--r--  1 root root  7934 Jan 28 23:15 dumper.py
-rw-r--r--  2 root root  6208 Jan 28 23:15 dumper.pyc
-rw-r--r--  2 root root  6208 Jan 28 23:15 dumper.pyo
-rw-r--r--  1 root root 14478 Jan 28 23:15 girparser.py
-rw-r--r--  1 root root 13361 Jan 28 23:15 girparser.pyc
-rw-r--r--  1 root root 13288 Jan 28 23:15 girparser.pyo
-rw-r--r--  1 root root 20233 Jan 28 23:15 girwriter.py
-rw-r--r--  1 root root 19000 Jan 28 23:15 girwriter.pyc
-rw-r--r--  1 root root 18915 Jan 28 23:15 girwriter.pyo
-rwxr-xr-x  1 root root 77304 Jan 28 23:15 _giscanner.so
-rw-r--r--  1 root root  5697 Jan 28 23:15 glibast.py
-rw-r--r--  2 root root  7022 Jan 28 23:15 glibast.pyc
-rw-r--r--  2 root root  7022 Jan 28 23:15 glibast.pyo
-rw-r--r--  1 root root 39466 Jan 28 23:15 glibtransformer.py
-rw-r--r--  1 root root 31967 Jan 28 23:15 glibtransformer.pyc
-rw-r--r--  1 root root 31927 Jan 28 23:15 glibtransformer.pyo
-rw-r--r--  1 root root   860 Jan 28 23:15 __init__.py
-rw-r--r--  2 root root   123 Jan 28 23:15 __init__.pyc
-rw-r--r--  2 root root   123 Jan 28 23:15 __init__.pyo
-rw-r--r--  1 root root  2106 Jan 28 23:15 libtoolimporter.py
-rw-r--r--  2 root root  1887 Jan 28 23:15 libtoolimporter.pyc
-rw-r--r--  2 root root  1887 Jan 28 23:15 libtoolimporter.pyo
-rw-r--r--  1 root root  2988 Jan 28 23:15 minixpath.py
-rw-r--r--  2 root root  1932 Jan 28 23:15 minixpath.pyc
-rw-r--r--  2 root root  1932 Jan 28 23:15 minixpath.pyo
-rw-r--r--  1 root root  1380 Jan 28 23:15 odict.py
-rw-r--r--  2 root root  1303 Jan 28 23:15 odict.pyc
-rw-r--r--  2 root root  1303 Jan 28 23:15 odict.pyo
-rw-r--r--  1 root root 13483 Jan 28 23:15 scannermain.py
-rw-r--r--  2 root root 10428 Jan 28 23:15 scannermain.pyc
-rw-r--r--  2 root root 10428 Jan 28 23:15 scannermain.pyo
-rw-r--r--  1 root root  3940 Jan 28 23:15 shlibs.py
-rw-r--r--  2 root root  2246 Jan 28 23:15 shlibs.pyc
-rw-r--r--  2 root root  2246 Jan 28 23:15 shlibs.pyo
-rw-r--r--  1 root root  7790 Jan 28 23:15 sourcescanner.py
-rw-r--r--  1 root root  9509 Jan 28 23:15 sourcescanner.pyc
-rw-r--r--  1 root root  9453 Jan 28 23:15 sourcescanner.pyo
-rw-r--r--  1 root root 26273 Jan 28 23:15 transformer.py
-rw-r--r--  1 root root 22565 Jan 28 23:15 transformer.pyc
-rw-r--r--  1 root root 22501 Jan 28 23:15 transformer.pyo
-rw-r--r--  1 root root  3587 Jan 28 23:15 utils.py
-rw-r--r--  2 root root  2656 Jan 28 23:15 utils.pyc
-rw-r--r--  2 root root  2656 Jan 28 23:15 utils.pyo
-rw-r--r--  1 root root  5165 Jan 28 23:15 xmlwriter.py
-rw-r--r--  1 root root  4980 Jan 28 23:15 xmlwriter.pyc
-rw-r--r--  1 root root  4903 Jan 28 23:15 xmlwriter.pyo


[x@alanine ~]$ rpm -qf /usr/lib64/python2.6/site-packages/*gi*
gobject-introspection-devel-0.6.8-0.1.20100128git.x86_64
Comment 5 Dave Malcolm 2010-03-03 15:31:33 EST
Baris: thanks for the information!  I believe what you posted is the contents of
the directory "/usr/lib64/python2.6/site-packages/giscanner" (sorry, my instructions weren't as clear as they could be)

I also have that installed on my F16 i686 box, and I'm able to successfully run the gnome-timer-applet.

So I'm afraid I'm somewhat mystified as to where that error message came from.

Does the applet work for you reliably?
Comment 6 Dave Malcolm 2010-03-03 15:32:19 EST
(In reply to comment #5)

> I also have that installed on my F16 i686 box, and I'm able to successfully run
> the gnome-timer-applet.
"F12", this should have read
Comment 7 Baris Cicek 2010-03-03 15:43:34 EST
Actually applet works reliably (well at least stays on panel). But I just reported this bug since something is somehow broken. If you need more info to triage I can help. Here's the list of the directory:

[x@alanine ~]$ ls -l /usr/lib64/python2.6/site-packages/giscanner
total 756
-rw-r--r-- 1 root root 30165 Jan 28 23:15 annotationparser.py
-rw-r--r-- 1 root root 28082 Jan 28 23:15 annotationparser.pyc
-rw-r--r-- 1 root root 27911 Jan 28 23:15 annotationparser.pyo
-rw-r--r-- 1 root root 15216 Jan 28 23:15 ast.py
-rw-r--r-- 2 root root 20333 Jan 28 23:15 ast.pyc
-rw-r--r-- 2 root root 20333 Jan 28 23:15 ast.pyo
-rw-r--r-- 1 root root  4300 Jan 28 23:15 cachestore.py
-rw-r--r-- 2 root root  3371 Jan 28 23:15 cachestore.pyc
-rw-r--r-- 2 root root  3371 Jan 28 23:15 cachestore.pyo
-rw-r--r-- 1 root root   978 Jan 28 23:15 config.py
-rw-r--r-- 2 root root   294 Jan 28 23:15 config.pyc
-rw-r--r-- 2 root root   294 Jan 28 23:15 config.pyo
-rw-r--r-- 1 root root  7934 Jan 28 23:15 dumper.py
-rw-r--r-- 2 root root  6208 Jan 28 23:15 dumper.pyc
-rw-r--r-- 2 root root  6208 Jan 28 23:15 dumper.pyo
-rw-r--r-- 1 root root 14478 Jan 28 23:15 girparser.py
-rw-r--r-- 1 root root 13361 Jan 28 23:15 girparser.pyc
-rw-r--r-- 1 root root 13288 Jan 28 23:15 girparser.pyo
-rw-r--r-- 1 root root 20233 Jan 28 23:15 girwriter.py
-rw-r--r-- 1 root root 19000 Jan 28 23:15 girwriter.pyc
-rw-r--r-- 1 root root 18915 Jan 28 23:15 girwriter.pyo
-rwxr-xr-x 1 root root 77304 Jan 28 23:15 _giscanner.so
-rw-r--r-- 1 root root  5697 Jan 28 23:15 glibast.py
-rw-r--r-- 2 root root  7022 Jan 28 23:15 glibast.pyc
-rw-r--r-- 2 root root  7022 Jan 28 23:15 glibast.pyo
-rw-r--r-- 1 root root 39466 Jan 28 23:15 glibtransformer.py
-rw-r--r-- 1 root root 31967 Jan 28 23:15 glibtransformer.pyc
-rw-r--r-- 1 root root 31927 Jan 28 23:15 glibtransformer.pyo
-rw-r--r-- 1 root root   860 Jan 28 23:15 __init__.py
-rw-r--r-- 2 root root   123 Jan 28 23:15 __init__.pyc
-rw-r--r-- 2 root root   123 Jan 28 23:15 __init__.pyo
-rw-r--r-- 1 root root  2106 Jan 28 23:15 libtoolimporter.py
-rw-r--r-- 2 root root  1887 Jan 28 23:15 libtoolimporter.pyc
-rw-r--r-- 2 root root  1887 Jan 28 23:15 libtoolimporter.pyo
-rw-r--r-- 1 root root  2988 Jan 28 23:15 minixpath.py
-rw-r--r-- 2 root root  1932 Jan 28 23:15 minixpath.pyc
-rw-r--r-- 2 root root  1932 Jan 28 23:15 minixpath.pyo
-rw-r--r-- 1 root root  1380 Jan 28 23:15 odict.py
-rw-r--r-- 2 root root  1303 Jan 28 23:15 odict.pyc
-rw-r--r-- 2 root root  1303 Jan 28 23:15 odict.pyo
-rw-r--r-- 1 root root 13483 Jan 28 23:15 scannermain.py
-rw-r--r-- 2 root root 10428 Jan 28 23:15 scannermain.pyc
-rw-r--r-- 2 root root 10428 Jan 28 23:15 scannermain.pyo
-rw-r--r-- 1 root root  3940 Jan 28 23:15 shlibs.py
-rw-r--r-- 2 root root  2246 Jan 28 23:15 shlibs.pyc
-rw-r--r-- 2 root root  2246 Jan 28 23:15 shlibs.pyo
-rw-r--r-- 1 root root  7790 Jan 28 23:15 sourcescanner.py
-rw-r--r-- 1 root root  9509 Jan 28 23:15 sourcescanner.pyc
-rw-r--r-- 1 root root  9453 Jan 28 23:15 sourcescanner.pyo
-rw-r--r-- 1 root root 26273 Jan 28 23:15 transformer.py
-rw-r--r-- 1 root root 22565 Jan 28 23:15 transformer.pyc
-rw-r--r-- 1 root root 22501 Jan 28 23:15 transformer.pyo
-rw-r--r-- 1 root root  3587 Jan 28 23:15 utils.py
-rw-r--r-- 2 root root  2656 Jan 28 23:15 utils.pyc
-rw-r--r-- 2 root root  2656 Jan 28 23:15 utils.pyo
-rw-r--r-- 1 root root  5165 Jan 28 23:15 xmlwriter.py
-rw-r--r-- 1 root root  4980 Jan 28 23:15 xmlwriter.pyc
-rw-r--r-- 1 root root  4903 Jan 28 23:15 xmlwriter.pyo
Comment 8 Dave Malcolm 2010-03-04 18:43:40 EST
Thanks for the information.

I'm afraid I'm somewhat mystified by this report; I can't see where the reference to "gi" came from, and I'm not sure where to investigate further.

Given that it's working for you now, I'm going to close this bug report (marking it with "INSUFFICIENT_DATA", for want of a better state).  I'm sorry that I'm not able to give you a more substantial response at this time.

Please reopen this bug if the problem happens again.
Comment 9 Chris Ball 2010-03-23 22:12:44 EDT
I'm seeing this with pitivi git HEAD on F14 (Rawhide), with a slightly different backtrace.  Any suggestions?  Thanks.

pullcord:cjb~/git/pitivi % bin/pitivi ~/lilypad.xptv
Traceback (most recent call last):
  File "pitivi/ui/exportsettingswidget.py", line 375, in _vcodecSettingsButtonClickedCb
    settings = self.runSettingsDialog(factory, self.vcodecsettings)
  File "pitivi/ui/exportsettingswidget.py", line 335, in runSettingsDialog
    dialog = GstElementSettingsDialog(factory, settings)
  File "pitivi/ui/gstwidget.py", line 191, in __init__
    self._fillWindow()
  File "pitivi/ui/gstwidget.py", line 200, in _fillWindow
    self.widgets["elementsettings"].setElement(self.element, self.properties)
  File "pitivi/ui/gstwidget.py", line 135, in setElement
    self._addWidgets(properties)
  File "pitivi/ui/gstwidget.py", line 151, in _addWidgets
    widget = make_property_widget(self.element, prop, properties.get(prop.name))
  File "pitivi/ui/gstwidget.py", line 103, in make_property_widget
    log.log("gstwidget", "adding %s / %s", val.value_name, val)
  File "pitivi/log/log.py", line 628, in log
    logObject(None, cat, format, *args)
  File "pitivi/log/log.py", line 393, in logObject
    doLog(LOG, object, cat, format, args)
  File "pitivi/log/log.py", line 330, in doLog
    if level > getCategoryLevel(category):
  File "pitivi/log/log.py", line 152, in getCategoryLevel
    registerCategory(category)
  File "pitivi/log/log.py", line 131, in registerCategory
    if category in fnmatch.filter((category, ), spec):
  File "/usr/lib64/python2.6/fnmatch.py", line 42, in filter
    import os,posixpath
ImportError: No module named gi
Comment 10 Christoph Wickert 2010-03-23 22:37:57 EDT
I think this has nothing to do with this bug, please file one against pitivi.
Comment 11 Chris Ball 2010-03-23 23:06:24 EDT
I disagree.  The parallels are:

* the backtrace appears in a file in /usr/lib64/python2.6, and not in the application code.
* the backtrace is garbled, and trying to import a module that doesn't exist.  This surely shouldn't happen.  The non-existent module ("gi") is the same for both applications, despite it not being referenced by either application.
* the bug is not seen on F12, with *the same application code*.

I conclude that this is most likely to be a python-wide problem in Rawhide.
Comment 12 Thomas Spura 2010-03-24 05:47:23 EDT
(In reply to comment #11)
> I conclude that this is most likely to be a python-wide problem in Rawhide.    

I once saw this on F-13. Rerunning the program in the same way and this backtrace was not reproducable anymore...

Chris, can you reproduce this more than just once?
Comment 13 Chris Ball 2010-03-24 09:25:11 EDT
Hi Thomas,

Yes, it's 100% reproducible.  Let me know if you have any debugging ideas.

Thanks.
Comment 14 Dave Malcolm 2010-03-24 10:18:28 EDT
(In reply to comment #13)
> Hi Thomas,
> 
> Yes, it's 100% reproducible.  Let me know if you have any debugging ideas.

Chris: do you have a recipe for reproducing this that I can try?
Comment 15 Dave Malcolm 2010-03-24 10:25:22 EDT
(In reply to comment #11)
> I conclude that this is most likely to be a python-wide problem in Rawhide.    
I'm inclined to agree.  Reopening.

CCing walters: Colin: it looks like this relates to gnome introspection - have you seen this before?  any ideas?
Comment 16 Thomas Spura 2010-03-24 10:41:46 EDT
*** Bug 576587 has been marked as a duplicate of this bug. ***
Comment 17 Chris Ball 2010-03-24 10:45:21 EDT
For me the recipe is:

  git clone git://git.pitivi.org/pitivi
  cd pitivi
  ./autogen.sh && make
  bin/pitivi

  Choose "import clips", find a video file, then drag it to the timeline
  Choose "render project"
  Choose an output filename
  Click on settings->modify
  Click on export to->video codec->Settings

Then, when the video settings dialog appears, you'll see the traceback.  I've just reproduced this on a different Rawhide machine, so I'm pretty confident you'll hit it too.  This one's 32-bit rather than 64-bit.
Comment 18 Colin Walters 2010-03-25 19:15:55 EDT
Building http://koji.fedoraproject.org/koji/taskinfo?taskID=2076272 now, am interested to know if it resolves it.
Comment 19 Chris Ball 2010-03-25 20:21:40 EDT
No, doesn't seem to change the behavior at all, sorry.

(Perhaps there could be cleanup of the previously-installed files that I need to do independently of upgrading to your RPM?)
Comment 20 Chris Ball 2010-03-25 20:29:12 EDT
I also *uninstalled* gobject-introspection, and that doesn't prevent the traceback either.
Comment 21 Colin Walters 2010-03-26 09:26:30 EDT
Ok, this appears likely to be because our pygobject2 is compiled with --enable-pygi.  I'm going to punt on that for F-13.
Comment 22 Colin Walters 2010-03-26 09:34:23 EDT
Would appreciate testing of 

http://koji.fedoraproject.org/koji/taskinfo?taskID=2077170
Comment 23 Christoph Wickert 2010-03-26 12:14:09 EDT
*** Bug 577276 has been marked as a duplicate of this bug. ***
Comment 24 Michal Schmidt 2010-03-26 12:40:02 EDT
(In reply to comment #22)
> Would appreciate testing of 
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=2077170    

Looks good. With the pygobject2-2.21.1-3.fc13.x86_64 there was about 40 % chance that the timer applet would cause the strange ImportError right after logging into Gnome.
With this new build (-4) I have not seen the error appear.
Comment 25 Michal Schmidt 2010-03-27 07:31:37 EDT
Perhaps I spoke too soon. Though I can't reproduce the error with the timer applet anymore, I received a similar error when using Gajim today:

Traceback (most recent call last):
  File "/usr/share/gajim/src/message_window.py", line 754, in _on_notebook_switch_page
    new_ctrl = self._widget_to_control(notebook.get_nth_page(page_num))
  File "/usr/share/gajim/src/message_window.py", line 624, in _widget_to_control
    if ctrl.widget == widget:
ImportError: No module named gi
Comment 26 Chris Ball 2010-03-28 22:57:51 EDT
Didn't fix it for me either, I'm afraid.  In fact, I now get a traceback earlier than before:

t60p:cjb~/git/pitivi % bin/pitivi                                              
/usr/lib/python2.6/site-packages/gtk-2.0/gtk/__init__.py:40: RuntimeWarning: tp_compare didn't return -1 or -2 for exception
  from gtk import _gtk
ImportError: No module named gi
Traceback (most recent call last):
  File "pitivi/utils.py", line 469, in _registryFeatureAddedCb
    log.warning("utils", "New feature added, invalidating cached factories")
  File "pitivi/log/log.py", line 616, in warning
    warningObject(None, cat, format, *args)
  File "pitivi/log/log.py", line 372, in warningObject
    doLog(WARN, object, cat, format, args)
  File "pitivi/log/log.py", line 330, in doLog
    if level > getCategoryLevel(category):
  File "pitivi/log/log.py", line 152, in getCategoryLevel
    registerCategory(category)
  File "pitivi/log/log.py", line 131, in registerCategory
    if category in fnmatch.filter((category, ), spec):
  File "/usr/lib/python2.6/fnmatch.py", line 42, in filter
    import os,posixpath
ImportError: No module named gi
Comment 27 Thomas Spura 2010-04-13 19:40:46 EDT
*** Bug 582047 has been marked as a duplicate of this bug. ***
Comment 28 Colin Walters 2010-05-04 10:10:19 EDT
*** Bug 588465 has been marked as a duplicate of this bug. ***
Comment 29 Colin Walters 2010-05-05 14:06:45 EDT
Created attachment 411699 [details]
clear error
Comment 30 Colin Walters 2010-05-05 14:08:59 EDT
Sorry that this one dropped off my radar.  We should definitely consider nominating this for a F-13 blocker.  Testing of the patch here appreciated, I'll do a quick scratch build.
Comment 31 Dave Malcolm 2010-05-05 14:19:23 EDT
(In reply to comment #29)
> Created an attachment (id=411699) [details]
> clear error    

I looked through pygobject, looking at the various places where
pygi_type_import_by_g_type is called, and in each case, if a NULL PyObject* is
returned, the code carries on with a fallback, leaving the error unhandled.  So
it does indeed look like we need to clear the error, as your patch does.
Comment 32 Colin Walters 2010-05-05 14:23:14 EDT
I'd like to propose this as a F-13 blocker, because pygobject2 is widely used, and the error here is likely to cause subtle failures in unrelated codepaths.

Risk of regressions from patch: I'd evaluate as "low" - we audited the callers and are confident.

Alternative approaches: We could --disable-pygi
Comment 33 Colin Walters 2010-05-05 14:24:05 EDT
Proposed build is:

http://koji.fedoraproject.org/koji/taskinfo?taskID=2165331
Comment 34 Thomas Spura 2010-05-05 14:41:13 EDT
Hmm, I'm unsure how to test this...

This happend randomly and just 4-5 times in total.

Would be installing the koji build and not seeing a crash enought?

I saw the last crash yesterday, the one before, I don't remember anymore, might be 2-3 weeks...
Comment 35 Fedora Update System 2010-05-05 14:53:05 EDT
pygobject2-2.21.1-5.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/pygobject2-2.21.1-5.fc13
Comment 36 Colin Walters 2010-05-05 14:54:26 EDT
Proposed Bodhi update:

https://admin.fedoraproject.org/updates/pygobject2-2.21.1-5.fc13
Comment 37 Colin Walters 2010-05-05 16:14:05 EDT
Let me try to characterize this bug a little bit better.

Originally in pygobject2-2.21.1-2 (before Thomas added --enable-pygi from bug 558003), we'd be calling PyErr_SetString when we tried to look for PyGI, but returning success.  The reason this blew up with the _locale import isn't entirely clear to me (but not very important for resolving this blocker right now).  In *some* code paths the code at this point called PyErr_Clear(), but not *all* of them.

Next in pygobject2-2.21.1-3 where --enable-pygi is passed to configure (what's in Fedora 13 now, since I never made an update for -4), we now set an ImportError, and note that that's exactly the exception that the _locale code was catching.  So that's why it appeared to fix the bug.

But we still had the fundamental problem that we were setting a Python exception, but leaving it around for some totally unrelated code to wander into later.  Upstream developer Simon tried to bring some sanity to this in the patch I added in -4 (upstream bug http://bugzilla.gnome.org/607674 ) by removing the exception if pygi support was *disabled*, but he still left the ImportError lying around in the case where it's *enabled* by configure but where pygi is not installed (as is default in Fedora).

Finally, my patch in -5 on top of Simon's, as audited by both me and dmalcolm, ensures that we don't leave any exception set in either the enabled or disabled case.

In summary, my take here is that other operating system creators aren't passing --enable-pygi, and are likely using Simon's patch.  Actually I just checked on patches.ubuntu.com, and that is indeed the case for them.
Comment 38 Colin Walters 2010-05-05 16:19:08 EDT
So in terms of reproducing this, we only have the pitivi case at this point.

What we don't have is a good characterization of all the things that break.  There are 4 duplicates against this bug for 4 different projects.  My guess is there are likely more.

Thinking about this a bit more, my action suggestion here is to pass --disable-pygi and use Simon's patch, and at that point we'll be in sync with what Ubuntu is doing. 

My patch should still go upstream, and for Fedora 14 we should enable pygi, but that's a later discussion.
Comment 39 Colin Walters 2010-05-05 16:55:29 EDT
The -6 build removes my patch and disables pygi.

https://admin.fedoraproject.org/updates/pygobject2-2.21.1-6.fc13
Comment 40 Fedora Update System 2010-05-06 03:03:49 EDT
pygobject2-2.21.1-6.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

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