abrt version: 1.1.13 architecture: i686 component: Miro executable: /usr/lib/python2.6/site-packages/miro/plat/renderers/gst_extractor.py kernel: 2.6.33.8-149.fc13.i686.PAE package: Miro-3.0.2-1.fc13 reason: __init__.py:52:_init:RuntimeError: could not open display release: Fedora release 13 (Goddard) time: 1283647033 uid: 500 backtrace ----- __init__.py:52:_init:RuntimeError: could not open display Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/miro/plat/renderers/gst_extractor.py", line 33, in <module> import gtk File "/usr/lib/python2.6/site-packages/gtk-2.0/gtk/__init__.py", line 64, in <module> _init() File "/usr/lib/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/lib/python2.6/site-packages/miro/plat/renderers', '/usr/lib/python26.zip', '/usr/lib/python2.6', '/usr/lib/python2.6/plat-linux2', '/usr/lib/python2.6/lib-tk', '/usr/lib/python2.6/lib-old', '/usr/lib/python2.6/lib-dynload', '/usr/lib/python2.6/site-packages', '/usr/lib/python2.6/site-packages/PIL', '/usr/lib/python2.6/site-packages/gst-0.10', '/usr/lib/python2.6/site-packages/gtk-2.0', '/usr/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg-info', '/usr/lib/python2.6/site-packages/webkit-1.0', '/usr/lib/python2.6/site-packages/wx-2.8-gtk2-unicode']
Created an attachment (id=447327) File: backtrace
Created attachment 448355 [details] Patch for Miro to exit gracefully when there is no available display Miro, quite obviously, needs a display to work. But perhaps this can be handled without crashing, and with a better error message?
Filed upstream, http://bugzilla.pculture.org/show_bug.cgi?id=14610
Miro-3.0.3-2.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/Miro-3.0.3-2.fc13
Miro-3.0.3-2.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/Miro-3.0.3-2.fc14
(In reply to comment #2) > Created attachment 448355 [details] > Patch for Miro to exit gracefully when there is no available display > > Miro, quite obviously, needs a display to work. But perhaps this can be handled > without crashing, and with a better error message? As a side note, there's a curses interface for Miro: miro --frontend=cli It's a feature we don't spend a ton of time on, but I'm pretty sure someone goes through to make sure it mostly works for each release. This interface does not require a working DISPLAY.
(In reply to comment #6) > (In reply to comment #2) > > Created attachment 448355 [details] [details] > > Patch for Miro to exit gracefully when there is no available display > > > > Miro, quite obviously, needs a display to work. But perhaps this can be handled > > without crashing, and with a better error message? > > As a side note, there's a curses interface for Miro: > > miro --frontend=cli > Hi Will, Interesting. Two thoughts: 1. how useful is this front-end? 2. should running miro without $DISPLAY set provide a suggestion that the CLI option is used? I won't pull the update I've already pushed out, but perhaps the wording could be changed upstream for 3.0.4 or whatever number ended up on the next release.
Hm, interesting. $ miro --frontend=cli ImportError on miro.plat.frontends.cli: No Module named cli Startup success. Startup complete. > _ But it works after that, more or less (the testdialog command goes into an infinite Q-and-A loop)
Miro-3.0.3-2.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update Miro'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/Miro-3.0.3-2.fc14
(In reply to comment #7) > Interesting. Two thoughts: > 1. how useful is this front-end? Not to be coy, but it depends on what your needs are. > 2. should running miro without $DISPLAY set provide a suggestion that the CLI > option is used? I won't pull the update I've already pushed out, but perhaps > the wording could be changed upstream for 3.0.4 or whatever number ended up on > the next release. I don't think it should. I applied the patch and it'll come out in Miro 3.5. (In reply to comment #8) > Hm, interesting. > > $ miro --frontend=cli > ImportError on miro.plat.frontends.cli: No Module named cli > > > Startup success. > Startup complete. > > _ > > But it works after that, more or less (the testdialog command goes into an > infinite Q-and-A loop) I can't remember if I did the pass for Miro 3.0, but I think I did previous passes. I tend to flit through the interface and make sure it can do the things I tend to do. This frontend is not well supported and definitely needs more attention. I just wanted to point out that it does exist, so if someone needed to use Miro over ssh without forwarding x, they could do so--albeit limitedly. The ImportError is just logging that Miro does as it looks for the cli frontends. Miro allows for arbitrary frontends. I'd love to get some help with this frontend if anyone is interested. Regardless, this bug will be fixed upstream in 3.5.
(In reply to comment #10) > I'd love to get some help with this frontend if anyone is interested. > I am certainly interested. Perhaps you could mail me off-list (well, off this bug entry) and we can talk about what you plan for the CLI frontend in the 3.5 development cycle? Thanks -- Michel
Miro-3.0.3-2.fc12 has been submitted as an update for Fedora 12. https://admin.fedoraproject.org/updates/Miro-3.0.3-2.fc12
Miro-3.0.3-2.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
Miro-3.0.3-2.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
Miro-3.0.3-2.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.