abrt 1.0.2 detected a crash. backtrace ----- Summary: TB4f66cc03 __init__.py:52:_init:RuntimeError: could not open display Traceback (most recent call last): File "/usr/lib64/timer-applet/timer-applet", line 22, in <module> import gtk File "/usr/lib64/python2.6/site-packages/gtk-2.0/gtk/__init__.py", line 64, in <module> _init() File "/usr/lib64/python2.6/site-packages/gtk-2.0/gtk/__init__.py", line 52, in _init _gtk.init_check() RuntimeError: could not open display Local variables in innermost frame: sys: <module 'sys' (built-in)> sys_path: ['/usr/lib64/timer-applet', '/usr/lib64/python26.zip', '/usr/lib64/python2.6', '/usr/lib64/python2.6/plat-linux2', '/usr/lib64/python2.6/lib-tk', '/usr/lib64/python2.6/lib-old', '/usr/lib64/python2.6/lib-dynload', '/usr/lib64/python2.6/site-packages', '/usr/lib64/python2.6/site-packages/PIL', '/usr/lib64/python2.6/site-packages/gst-0.10', '/usr/lib64/python2.6/site-packages/gtk-2.0', '/usr/lib64/python2.6/site-packages/webkit-1.0', '/usr/lib/python2.6/site-packages'] cmdline: python /usr/lib64/timer-applet/timer-applet --oaf-activate-iid=OAFIID:TimerApplet_Factory --oaf-ior-fd=21 component: gnome-applet-timer executable: /usr/lib64/timer-applet/timer-applet kernel: 2.6.31.9-174.fc12.x86_64 package: gnome-applet-timer-2.1.2-6.fc12 uuid: 4f66cc03
Created attachment 382543 [details] File: backtrace
Hi, thanks for the bug report. How can you reproduce this bug? It seems, you ran this without X or something like this. But this is then no gnome-applet-timer bug, this should be a pygtk2 bug in this case. Assigning to pygtk2.
I don't see how this can be a pygtk2 issue. The user tried to run an X application without X. That has to fail, and pygtk2 do the right thing by raising an exception. It is ugly that it do the check and raises the exception in "import gtk", but that is how it is, and applications must thus place an exception handler around the import. FWIW, similar behaviour is seen with most other pygtk apps, for example "DISPLAY= gnome-about".
(In reply to comment #3) > I don't see how this can be a pygtk2 issue. > > The user tried to run an X application without X. That has to fail, and pygtk2 > do the right thing by raising an exception. It is ugly that it do the check and > raises the exception in "import gtk", but that is how it is, and applications > must thus place an exception handler around the import. > > FWIW, similar behaviour is seen with most other pygtk apps, for example > "DISPLAY= gnome-about". It doesn't make sence to start a gui without X. If there is no X, the gui should not even start and so don't send a backtrace to abrt. Don't know what is responsible for that, but fixing every gui application to cleanly close again, once there is no X doesn't make sense to me at all. So this should be a gnome starter bug. Without X there should be no gnome, and without a proper starting gnome, no gui app should get started. Feel free to assign to, where it belongs...
(In reply to comment #4) > Don't know what is responsible for that, but fixing every gui application to > cleanly close again, once there is no X doesn't make sense to me at all. I am afraid that the only possible answer is that every gui application has to be fixed. What is the alternative? That pygtk should raise a SystemExit instead of a RuntimeError? I don't think it is pygtk's job to decide that the application should exit just because X isn't available. If that is what the application want then it should catch the RuntimeError on import and raise SystemExit.
(In reply to comment #5) > (In reply to comment #4) > > Don't know what is responsible for that, but fixing every gui application to > > cleanly close again, once there is no X doesn't make sense to me at all. > > I am afraid that the only possible answer is that every gui application has to > be fixed. Or don't start the application at all. Fixing the session-manager to verify, that X is there, and after that, start all programs. This way no gui application would get started, when there is no X, so the applications would only crash, when you call them from the console manually and have no X started. This looks more like a user error, than a bug to me... In this case, it seems X was not started properly, and maybe crashed the X server in the same time, like starting gnome-applet-timer, so this is definetely no user error. This could be gnome-session, or something else on the gnome site... Would that be an alternative for you too?
Yes, if it can be reproduced that gnome-session starts applets without X then I think the issue should be assigned there. But I can imagine that something like this happened: X and GNOME was started, the timer applet got launched correctly somehow, but before the applet really started X died for some reason, so when the applet asked pygtk to connect to DISPLAY it couldn't and reported that back to the applet the right way for a python program: by raising an exception. (FWIW, I still think the only solution is that the application/applet should handle no-X by trying to write a message to stderr (without failing if it can't) and die decently. It is however a rare situation, so perhaps we don't care.)
(In reply to comment #7) > Yes, if it can be reproduced that gnome-session starts applets without X then I > think the issue should be assigned there. I don't think this can be properly reproduced again... I still don't think it's worth the effort, furthermore upstream is deat, so this would be a fedora specific fix anyway, but the fix will find it's way through CVS right now... http://cvs.fedoraproject.org/viewvc/devel/gnome-applet-timer/gnome-applet-timer-2.1.2-gtk-runtimerror.patch?view=markup Leaving this open, so the gnome folks, can handle it too...
gnome-applet-timer-2.1.2-7.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/gnome-applet-timer-2.1.2-7.fc13
gnome-applet-timer-2.1.2-7.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/gnome-applet-timer-2.1.2-7.fc12
gnome-applet-timer-2.1.2-7.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
gnome-applet-timer-2.1.2-7.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.