Summary: | media-sound/quodlibet-2.5 - quodlibet: RuntimeError: maximum recursion depth exceeded while calling a Python object | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Manuel Ullmann <labre> |
Component: | Current packages | Assignee: | Gentoo Sound Team <sound> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | arne_bab, ewoud+gentoo, humberto.nanni |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Part of emerge.log with the suspect update
QuodLibet window displaying nothing Mostly empty preferences window |
Description
Manuel Ullmann
2013-12-06 19:32:03 UTC
Created attachment 364740 [details]
Part of emerge.log with the suspect update
This is the part of emerge.log, where the by me suspected update was running. You can see, that there are lots of python relevant packages. However not python-2.7 itself.
Created attachment 364742 [details]
QuodLibet window displaying nothing
Here you can see, that the content of view modes are not shown in quodlibet.
Note, that I am filing this in Gentoo bugzilla because the quodlibet-faq did say so. On the other hand it seems to me, that the last update introduced this bug. Created attachment 364918 [details]
Mostly empty preferences window
Just for the sake of completeness.
Opening the window or changing the view mode reprints the following lines:
Original exception was:
RuntimeError: maximum recursion depth exceeded while calling a Python object
Error in sys.excepthook:
RuntimeError: maximum recursion depth exceeded while calling a Python object
Did you run python-updater after upgrading dev-lang/python? $ eselect python list Available Python interpreters: [1] python2.7 * [2] python3.3 $ eselect python list --python3 Available Python 3 interpreters: [1] python3.3 * After eselecting the new interpreter I actually ran python-updater twice, because some virtual package was broken (environment.bz2). Manually unmerging and remerging resolved the problem. Remerging alone did not help. python-updater forgot to rebuild pytz. depclean complained about it. Manually rebuilding fixed the problem and depclean removed python-3.2. However quodlibet is built against python-2.7, so this should not be the reason anyway. Thanks for asking. ;-) Saw, that the summary was changed. I don't care about the missing ipod support. The USE-Flag is not set. The message that is reprinted, when changing the view mode or open the preferences window, was written in comment 4. Changing the summary therefore, as it does not state an important error. $ eix quodlibet [I] media-plugins/quodlibet-plugins Available versions: 2.4 2.5 {PYTHON_TARGETS="python2_7"} Installed versions: 2.5(15:46:19 05.10.2013)(PYTHON_TARGETS="python2_7") Homepage: http://code.google.com/p/quodlibet/ Description: Plugins for Quod Libet and Ex Falso [I] media-sound/quodlibet Available versions: 2.4 2.5 {(+)dbus gstreamer ipod +udev PYTHON_TARGETS="python2_7"} Installed versions: 2.5(18:13:33 06.12.2013)(dbus gstreamer udev -ipod PYTHON_TARGETS="python2_7") Homepage: http://code.google.com/p/quodlibet/ Description: audio library tagger, manager, and player for GTK+ Found 2 matches. If you need any additional information, just ask. ;-) I'm having the very same problem. I've fixed it by forcing the emerge of an old version of pygobject: emerge =dev-python/pygobject-2.28.6-r53 I can confirm that if I left the system to update to pygobject-2.28.6-r55:2 Calculating dependencies... done! [nomerge ] media-plugins/quodlibet-plugins-2.5 PYTHON_TARGETS="python2_7" [nomerge ] media-sound/quodlibet-2.5 USE="dbus gstreamer ipod udev" PYTHON_TARGETS="python2_7" [ebuild N ] dev-python/pygobject-2.28.6-r55:2 USE="-examples -libffi {-test}" PYTHON_TARGETS="python2_7 -python2_6" 0 kB quolibet breaks to the failure described in this bug. Going back to dev-python/pygobject-2.28.6-r53 fixes the problem Also, I can confirm pygobject is a real mess: * >=dev-python/pygobject-2.26.8-r53:2[python_targets_python2_7(-),-python_single_target_python2_6(-),-python_single_target_python2_7(-)] pulled in by: * dev-python/pygtk-2.24.0-r4 * * dev-python/pygobject:2 pulled in by: * media-sound/quodlibet-2.5 * * >=dev-python/pygobject-2.28:2[python_targets_python2_7(-),-python_single_target_python2_6(-),-python_single_target_python2_7(-)] pulled in by: * dev-python/gst-python-0.10.22-r1 * * >=dev-python/pygobject-2.15.2:2[python_targets_python2_7(-),-python_single_target_python2_6(-),-python_single_target_python2_7(-)] pulled in by: * dev-python/pygtksourceview-2.10.1-r1 * * >=dev-python/pygobject-2.15.3:2 pulled in by: * dev-libs/keybinder-0.3.0-r200 * * >=dev-python/pygobject-2.8:2 pulled in by: * media-libs/libgpod-0.8.2 Just as a side note, using pygobject-3.8.3 gives me no quodlibet at all: Traceback (most recent call last): File "/usr/bin/quodlibet", line 19, in <module> import quodlibet File "/usr/lib64/python2.7/site-packages/quodlibet/__init__.py", line 22, in <module> import quodlibet.util File "/usr/lib64/python2.7/site-packages/quodlibet/util/__init__.py", line 605, in <module> class DeferredSignal(object): File "/usr/lib64/python2.7/site-packages/quodlibet/util/__init__.py", line 620, in DeferredSignal import gobject ImportError: No module named gobject Downgrading to dev-python/pygobject-2.28.6-r53 indeed fixes the problem. Thank you for the tip. (In reply to Manuel Ullmann from comment #2) > Created attachment 364742 [details] > QuodLibet window displaying nothing > > Here you can see, that the content of view modes are not shown in quodlibet. Upstream replied that this is a known issue with quodlibet 2.5 (triggers a bug in pygtk): http://code.google.com/p/quodlibet/issues/detail?id=1304#c1 Solution: Update to 2.5.1 (which is not yet in portage). (In reply to Arne Babenhauserheide from comment #12) > Solution: Update to 2.5.1 (which is not yet in portage). Simply renaming the ebuild to quodlibet-2.5.1.ebuild works. My quodlibet shows lists again. Additionally to the basic solution (update the ebuild to the new version), I documented the bug solving process I used (because I had never done that before, and I think it should be more visible to new users how even complex problems can get solved without tons of domain knowledge): http://draketo.de/english/quod-libet-bug-solution-process You forgot to mention the creation of /usr/local/metadata/layout.conf. Otherwise portage will print a warning on invocation. Besides that, creating also the quodlibet-plugins ebuild is also useful, but I see, that this is not necessary. They both just needed to be renamed. By the way there is an version bump ongoing for quodlibet and -plugins (bug 475156 and bug 475160). However they want to bump to 3.0.2, which is the unstable branch. Don't know, why the stable tree is not bumped. I have never seen such a efficient player. According to top it just uses 0,4% more CPU load than gst-launch playbin on my AMD 2,3 GHz mobile CPU (Turion X2). (In reply to Manuel Ullmann from comment #15) > You forgot to mention the creation of /usr/local/metadata/layout.conf. > Otherwise portage will print a warning on invocation. Besides that, creating > also the quodlibet-plugins ebuild is also useful, but I see, that this is > not necessary. They both just needed to be renamed. You’re right, yes. (I guess you mean /usr/local/portage/metadata/layout.conf) Just having to rename ebuilds speaks for a solid build process of the package ☺ > By the way there is an version bump ongoing for quodlibet and -plugins (bug > 475156 and bug 475160). However they want to bump to 3.0.2, which is the > unstable branch. Don't know, why the stable tree is not bumped. I have never > seen such a efficient player. According to top it just uses 0,4% more CPU > load than gst-launch playbin on my AMD 2,3 GHz mobile CPU (Turion X2). I don’t understand that either. Quod Libet just keeps working, and I like that a lot. Since I disabled the rescan at startup it starts quickly and is usable at once - and it scales to the tens of thousands of songs in my music library. Sorry for the wrong path and writing a little bit unclear. As far as I understand, a version bump is writing a version of an ebuild. Usually this is done by gentoo devs, but somehow there seems not to be a maintainer for the quodlibet ebuilds. These version bumps are done in gentoo bugzilla to request testing and fixing any issues in the ebuild. Quodlibet is for quite a while now at version 2.6.3 on the developer website and 2.5.1 is there even longer. So there was plenty of time to at least version bump to 2.5.1, which would have fixed this bug before the pygtk version got stable. The only version bumps for quodlibet are at the moment those I mentioned, which are going to 3.0.2 and were not answered by gentoo devs. Never mind, I am just having a moan. ;-) (In reply to Manuel Ullmann from comment #17) > Sorry for the wrong path and writing a little bit unclear. No probs ☺ > As far as I understand, a version bump is writing a version of an ebuild. > Usually this is done by gentoo devs, but somehow there seems not to be a > maintainer for the quodlibet ebuilds. These version bumps are done in gentoo > bugzilla to request testing and fixing any issues in the ebuild. Normally a version bump happens by the maintainer. If the maintainer is inactive, it happens by some user renaming the ebuild, making it work with the new version and posting a request for a version bump with the ebuild. Developers are usually pretty quick to react to that. Key points: Not much work, the user already did the testing → Big return of investment. quodlibet-3.0.2 is now in Portage, so this can be closed Can we have in portage the 2.5.1 version of quodlibet[-plugins]? It works fine and emerging version 3.0.2 implies lots of stuff being added to my system. Plus, gnome3 programs are not honoring the color themes and the quodlibet plugins I wrote, no longer work in 3.0.2 [ebuild U ~] media-plugins/quodlibet-plugins-3.0.2 [2.5.1] PYTHON_TARGETS="python2_7" 109 kB [ebuild U ~] media-sound/quodlibet-3.0.2 [2.5.1] USE="dbus gstreamer ipod udev" PYTHON_TARGETS="python2_7" 3,975 kB [ebuild NS ] dev-python/pygobject-3.8.3:3 [2.28.6-r55:2] USE="cairo threads -examples {-test}" PYTHON_TARGETS="python2_7 python3_3 -python2_6 -python3_2" 642 kB [ebuild NS ] media-plugins/gst-plugins-meta-1.0-r1:1.0 [0.10-r8:0.10] USE="alsa ffmpeg flac http mp3 mpeg ogg taglib vorbis x264 -X -a52 -aac -cdda -dts -dv -dvb -dvd -jack -lame -libass -libvisual -mms -opus -oss -pulseaudio -theora -v4l -vcd (-vpx) -wavpack" 0 kB [ebuild N ] media-plugins/gst-plugins-libav-1.1.0_pre20130128-r1:1.0 USE="orc" 467 kB [ebuild NS ] dev-libs/keybinder-0.3.0-r300:3 [0.3.0-r200:0] USE="introspection" 339 kB [nomerge ] media-plugins/gst-plugins-meta-1.0-r1:1.0 [0.10-r8:0.10] USE="alsa ffmpeg flac http mp3 mpeg ogg taglib vorbis x264 -X -a52 -aac -cdda -dts -dv -dvb -dvd -jack -lame -libass -libvisual -mms -opus -oss -pulseaudio -theora -v4l -vcd (-vpx) -wavpack" [ebuild NS ] media-plugins/gst-plugins-flac-1.0.10:1.0 [0.10.31:0.10] 2,669 kB [ebuild NS ] media-plugins/gst-plugins-mad-1.0.10:1.0 [0.10.19:0.10] 811 kB [ebuild NS ] media-plugins/gst-plugins-mpeg2dec-1.0.10:1.0 [0.10.19:0.10] 0 kB [ebuild NS ] media-plugins/gst-plugins-x264-1.0.10:1.0 [0.10.19:0.10] 0 kB [ebuild NS ] media-plugins/gst-plugins-taglib-1.0.10:1.0 [0.10.31:0.10] 0 kB [ebuild NS ] media-plugins/gst-plugins-soup-1.0.10:1.0 [0.10.31:0.10] 0 kB [ebuild NS ] media-libs/gst-plugins-ugly-1.0.10:1.0 [0.10.19:0.10] USE="nls orc" 0 kB [ebuild NS ] media-libs/gst-plugins-good-1.0.10:1.0 [0.10.31:0.10] USE="nls orc" 0 kB [nomerge ] dev-python/pygobject-3.8.3:3 [2.28.6-r55:2] USE="cairo threads -examples {-test}" PYTHON_TARGETS="python2_7 python3_3 -python2_6 -python3_2" [ebuild N ] gnome-base/gnome-common-3.7.4:3 149 kB I just noted, that quodlibet-2.6.3 did hit the portage tree. Does this version solve your issues (e.g. is old enough)? I don´t know, how stable it is. However the quodlibet developers did not update it for a long time. If you have any issues, you should open another bug report. You could for example make a version bump request for 2.5.1, like the one for 3.0.2. Yep, it is working fine. Now I have the 3 version masked. Things seems stable here |