Hide Forgot
Description of problem: Gui won't start Version-Release number of selected component (if applicable): 5.0.5-1 How reproducible: On fc7 install bittorrent-5.0.5-1 Steps to Reproduce: 1.Update from working fc7 bittorrent-4.4.0-3 which was response to wxPython-2.8 coming out to bittorrent-5.0.5 which has same problem as code at bittorrent site which only works with python-2.4. 2. 3. Actual results: No gui Expected results: Gui Additional info: See my comment to Bug 223424 where someone wants 5.0.5 in fc6 extras.
Actually the 4.4.0-3 build in Rawhide was for the update to python 2.5. This issue appears to be related to the move to wx 2.8 rather than python 2.5, as an FC6 system upgraded to wx 2.8 has exactly the same problem. The initial 2.8 incompatibilities and deprecation warnings can be addressed by changing the wxversion request to 2.8 and commenting out the wxPython references: $ cd /usr/lib/python2.5/site-packages/BitTorrent/GUI_wx/ $ diff -u __init__.py.orig __init__.py --- __init__.py.orig 2007-01-21 07:06:51.000000000 -0500 +++ __init__.py 2007-01-22 04:38:13.000000000 -0500 @@ -22,13 +22,13 @@ else: # doesn't work in py2exe try: - wxversion.select('2.6') + wxversion.select('2.8') except: pass import wx import wx.grid -import wxPython +# import wxPython from BTL.translation import _ from BitTorrent.platform import image_root @@ -36,9 +36,9 @@ from BTL.defer import ThreadedDeferred import bisect -vs = wxPython.__version__ -min_wxpython = "2.6" -assert vs >= min_wxpython, _("wxPython version %s or newer required") % min_wxpython +#vs = wxPython.__version__ +#min_wxpython = "2.6" +#assert vs >= min_wxpython, _("wxPython version %s or newer required") % min_wxpython assert 'unicode' in wx.PlatformInfo, _("The Unicode versions of wx and wxPython are required") text_wrappable = wx.__version__[4] >= '2' Running "bittorrent" then results in a segfault at line 2898 of DownloadManager.py, which is: wx.LogGeneric(level, v_msg) The log message concerned is "[5.0.5] [NatTraversal] Trying: ManualUPnP" Commenting out this line results in a segfault at the next wx call. I did manage to get a backtrace from a core dump: Core was generated by `/usr/bin/python /usr/bin/bittorrent'. Program terminated with signal 11, Segmentation fault. #0 wxLog::OnLog (level=5, szString=0x1bac2b8, t=1169565034) at src/common/log.cpp:337 337 pLogger->DoLog(level, szString, t); ... Thread 1 (process 32154): #0 wxLog::OnLog (level=5, szString=0x1bac2b8, t=1169565034) at src/common/log.cpp:337 pLogger = (wxLog *) 0x170ab80 #1 0x00002aaab47b99dd in wxVLogGeneric (level=5, szFormat=0x1ba57e8, argptr=0x7fff2fddaa90) at src/common/log.cpp:90 No locals. #2 0x00002aaab47b9ac8 in wxLogGeneric (level=24161152, szFormat=0x5) at src/common/log.cpp:98 argptr = {{gp_offset = 16, fp_offset = 48, overflow_arg_area = 0x7fff2fddab70, reg_save_area = 0x7fff2fddaab0}} #3 0x00002aaab5a0dee9 in wxPyLogGeneric (level=5, msg=<value optimized out>) at src/gtk/_misc_wrap.cpp:3160 m = {<wxStringBase> = {static npos = 18446744073709551615, m_pchData = 0x1ba57e8}, <No data fields>} #4 0x00002aaab5a6616a in _wrap_LogGeneric (args=<value optimized out>, kwargs=<value optimized out>) at src/gtk/_misc_wrap.cpp:13944 __tstate = (PyThreadState *) 0x6012d0 resultobj = <value optimized out> arg2 = (wxString *) 0x1ab2960 obj0 = (PyObject *) 0x609508 obj1 = (PyObject *) 0x136e360 kwnames = {0x2aaab5aa223b "level", 0x2aaab5aa2241 "msg", 0x0} #5 0x0000003e1f636140 in PyObject_Call () from /usr/lib64/libpython2.4.so.1.0 No symbol table info available. (this was an FC6 x86_64 box updated with wx 2.8 built from the Rawhide wxGTK and wxPython SRPMs). I'm not sure whether this is a bittorrent issue or a wxwidgets issue; I'll try asking on the bittorrent bug reporting address to see what upstream thinks.
*** Bug 223636 has been marked as a duplicate of this bug. ***
Status update: I've exchanged several emails with Greg Hazel, who is one of the upstream BitTorrent maintainers. Greg confirmed that he'd experienced a similar problem with wxPython 2.7 a while back, but that the BitTorrent maintainers are sticking with wxPython 2.6 at least for the time being because 2.7/2.8 are significantly bigger (at least on Windows, and BitTorrent is developed primarily on Windows). We then tried finding a workaround for the problem but this ended up as a game of whack-a-mole with segfaults. First up, the "LogProxy" function was taken out of the loop by changing: wx.Log_SetActiveTarget(LogProxy(self.log)) to: wx.Log_SetActiveTarget(self.log) in BitTorrent/GUI_wx/DownloadManager.py, around line 3000. This then moved the problem to a segfault in the console subwindow, which Greg thought looked like a wxPython bug in wx.py.shell. He suggested turning off the console window as a workaround for that, by changing: console = True to: console = False at around line 87 of BitTorrent/GUI_wx/DownloadManager.py. The result of this was another segfault in the logging subsystem, so Greg suggested bypassing it by adding a "return" at the top of the do_log function that line 3650 of BitTorrent/GUI_wx/DownloadManager.py is in. The result of this was another segfault that implied to Greg that the whole event system was broken. So it looks like we need to get someone familiar with wxPython to take a look at it now.
Yes a had the same game last nite (fun isn't it) also down roughly the same code paths and ended in one big segfault, sadly I don't know any Python or wx so I wait for an expert opinion. azureus is busted too isn't rawhide so much Fun.
I've just made a change to the bittorrent package in rawhide (it'll probably hit the mirrors tomorrow), but don't all get excited; it fixes a couple of minor nits and should allow the GUI to get as far as the wx segfault. This will help with debugging when I try raising this with the wxPython maintainer. However, another avenue that is worth exploring now is whether the GUI will work on a system that has wxPython 2.6 installed in addition to or instead of the wxPython 2.8 from Extras. If no resolution to the wxPython 2.8 segfault issue can be found, it might be possible to create a compat-wxPython2.6 package to run the bittorrent GUI with.
Regarding Comment #5 where I referred to a compat-wxPython26 package, I've now put one together and it does indeed seem to solve the problem, which does suggest that the issue lies in the rawhide wxPython 2.8 package or the underlaying wxGTK package, which is supposed to be 2.6-compatible. I've also built wx 2.8 packages and the compat-2.6 packages for FC6, which exhibits exactly the same behaviour when upgraded to 2.8. Anyone wishing to try these can grab them from here: http://mirror.city-fan.org/wx-repo/
tried the compat packages: First it gave me a bug: $ bittorrent >>> unable to setrlimit not allowed to raise maximum limit Exception in thread bittorrent:263 in <module>: threading.Thread(target=init_core, args=(mainloop,)).start(): Traceback (most recent call last): File "/usr/bin/bittorrent", line 263, in <module> threading.Thread(target=init_core, args=(mainloop,)).start() File "/usr/bin/bittorrent", line 215, in init_core init_torrents=False) File "/usr/lib/python2.5/site-packages/BitTorrent/MultiTorrent.py", line 167, in __init__ self._restore_state(init_torrents) File "/usr/lib/python2.5/site-packages/BitTorrent/MultiTorrent.py", line 844, in _restore_state t = decode_line(line) File "/usr/lib/python2.5/site-packages/BitTorrent/MultiTorrent.py", line 758, in decode_line t.working_path = t.working_path.decode('utf-8') File "/usr/lib/python2.5/site-packages/BitTorrent/Torrent.py", line 268, in _set_working_path self.config['working_path'] = value File "/usr/lib/python2.5/site-packages/BitTorrent/prefs.py", line 50, in __setitem__ isinstance(value, str), "'%s' is not str" % option AssertionError: 'working_path' is not str non-daemon threads not shutting down in a timely fashion: <StackThread(disk_thread-1, started)> <StackThread(disk_thread-2, started)> <StackThread(disk_thread-3, started)> You have no chance to survive make your time. Killed but after moving the old ~/.bittorrent dir out of the way things seem to be working
I find the rpm @ http://mirror.city-fan.org/wx-repo/ unseable as to determine which rpm's to use in an rpm --uvh blah.rpm --oldpackage senario. I would need to yum update bittorrent bitterrent-gui first then --oldpackage for the 3 wx RPM's (but you have 5 and which are needed is undeterminable.) Then, if I were to try all the possible combinations, I have no .bittorent file as ~/.bittorrent (why I don't know.) I got the same messages that Sander got when I first installed it.) Also, now that you have found a solution what is going to happen? (wait, re-compile your pakages and bt 5.0.5 for extras, other?) Could you at least put an install txt file on your repo site? thanks, Darwin
OK, I tried the NON-DEVEL packages as rpm -uvh --olpackage after yum install bittorrent bittorrent-gui and it --test ED ok and when in. But I got the screen up on fist try with a message that said bittorent core failed to initialize. It hung for a few seconds and then disappeared. I tried to run IN a term but it would not start. I clciked on the program and it gave the same messages as Sander shows but the term exits. I then tried the DEVL RPM's as rpm -Uvh --oldpackage --test and got rpm -Uvh compat-wxGTK26-devel-2.6.3-2.6.3.2.1.fc7.i386.rpm compat-wxPython26-devel-2.6.3.2-1.fc7.i386.rpm --oldpackage --test warning: compat-wxGTK26-devel-2.6.3-2.6.3.2.1.fc7.i386.rpm: Header V3 DSA signature: NOKEY, key ID b56a8bac error: Failed dependencies: gtk2-devel is needed by compat-wxGTK26-devel-2.6.3-2.6.3.2.1.fc7.i386 libGL-devel is needed by compat-wxGTK26-devel-2.6.3-2.6.3.2.1.fc7.i386 libGLU-devel is needed by compat-wxGTK26-devel-2.6.3-2.6.3.2.1.fc7.i386 wxGTK-devel is needed by compat-wxGTK26-devel-2.6.3-2.6.3.2.1.fc7.i386 wxGTK-devel is needed by compat-wxPython26-devel-2.6.3.2-1.fc7.i386 Now I see that DEVL has 3 different contexts here. Your devl package the devl (rawhaide) system and the devl environment and that is beyound me as needing 5 dev packages installed with the rpm is probably looking at deps-hell by next week so I'll pass on that. Still .bittorretn file. Darwin
That should say "still no .bittorrent file" (to delete and try as Sander did. D
One more for the road. I got the idea that I had BOTH the normal and compat rpms installed and that didn't set right so I tried to re-do the whole whole thing. I did get the gui up and it sat there untill I clicked on file. Then I thot I needed to remove the wxPython (2.8) also and I did. But when I re-installed the 3 compat's rpm's the one compat wanted the orginal wxPython (2.8) package. That is beyound me. does seem like a replacement but rather an addition package? D rpm -qa wx* wxPython-2.8.0.1-1.fc7 wxGTK-2.8.0-2.8.0.1.3.fc7 wxGTK-gl-2.8.0-2.8.0.1.3.fc7 [root@Jovette-14 ~]# prm -qa compat-wx* -bash: prm: command not found [root@Jovette-14 ~]# rpm -qa compat-wx* compat-wxGTK26-gl-2.6.3-2.6.3.2.1.fc7 compat-wxGTK26-2.6.3-2.6.3.2.1.fc7 compat-wxPython26-2.6.3.2-1.fc7 [root@Jovette-14 ~]# rpm -e wxGTK-2.8.0-2.8.0.1.3.fc7 wxGTK-gl-2.8.0-2.8.0.1.3.fc7 --nodeps [root@Jovette-14 ~]# rpm -e wxPython-2.8.0.1-1.fc7 --nodeps [root@Jovette-14 ~]# rpm -e compat-wxGTK26-gl-2.6.3-2.6.3.2.1.fc7 compat-wxGTK26-2.6.3-2.6.3.2.1.fc7 compat-wxPython26-2.6.3.2-1.fc7 --nodeps [root@Jovette-14 ~]# cd /home/darwinhwebb/deck [root@Jovette-14 deck]# rpm -ivh compat-wxGTK26-gl-2.6.3-2.6.3.2.1.fc7 compat-wxGTK26-2.6.3-2.6.3.2.1.fc7 compat-wxPython26-2.6.3.2-1.fc7 --test error: open of compat-wxGTK26-gl-2.6.3-2.6.3.2.1.fc7 failed: No such file or directory error: open of compat-wxGTK26-2.6.3-2.6.3.2.1.fc7 failed: No such file or directory error: open of compat-wxPython26-2.6.3.2-1.fc7 failed: No such file or directory [root@Jovette-14 deck]# dir bittorrent-4.4.0-3.fc7.noarch.rpm f7-test1-dvd-i386.torrent bittorrent-5.0.5-2.fc7.noarch.rpm Fc7ThemeProposalEnergyInterferences bittorrent-gui-4.4.0-3.fc7.noarch.rpm fx3-execmem-chcon.txt bittorrent-gui-5.0.5-2.fc7.noarch.rpm kernel-2.6.19-1.2917.fc7.i686.rpm compat-wxGTK26-2.6.3-2.6.3.2.1.fc7.i386.rpm kernel-2.6.19-1.2919.fc7.i686.rpm compat-wxGTK26-devel-2.6.3-2.6.3.2.1.fc7.i386.rpm kernel-headers-2.6.19-1.2917.fc7.i386.rpm compat-wxGTK26-gl-2.6.3-2.6.3.2.1.fc7.i386.rpm kernel-headers-2.6.19-1.2919.fc7.i386.rpm compat-wxPython26-2.6.3.2-1.fc7.i386.rpm pungi-0.2.1-1.fc7.noarch.rpm compat-wxPython26-devel-2.6.3.2-1.fc7.i386.rpm sysklogd-1.4.1-45.fc7.i386.rpm [root@Jovette-14 deck]# rpm -ivh compat-wxPython26-2.6.3.2-1.fc7.i386.rpm compat-wxGTK26-2.6.3-2.6.3.2.1.fc7.i386.rpm compat-wxGTK26-gl-2.6.3-2.6.3.2.1.fc7.i386.rpm --test warning: compat-wxPython26-2.6.3.2-1.fc7.i386.rpm: Header V3 DSA signature: NOKEY, key ID b56a8bac error: Failed dependencies: wxPython is needed by compat-wxPython26-2.6.3.2-1.fc7.i386 [root@Jovette-14 deck]# rpm -qa wxPython [root@Jovette-14 deck]#
It actually started to work but I realized I was in root. At file quit I got these messages if they help. Going to exit out of root and try again. # bittorrent ** (python:3866): CRITICAL **: clearlooks_style_draw_focus: assertion `height >= -1' failed (python:3866): Gtk-CRITICAL **: gtk_container_remove: assertion `GTK_IS_TOOLBAR (container) || widget->parent == GTK_WIDGET (container)' failed (python:3866): Gtk-CRITICAL **: gtk_container_remove: assertion `GTK_IS_TOOLBAR (container) || widget->parent == GTK_WIDGET (container)' failed Unhandled exception in thread started by <bound method Reaper.__bootstrap of <Reaper(Thread-2, stopped daemon)>> Error in sys.excepthook: TypeError: 'NoneType' object is not callable Original exception was: Traceback (most recent call last): File "/usr/lib/python2.5/threading.py", line 482, in __bootstrap " (most likely raised during interpreter shutdown):") File "/usr/lib/python2.5/codecs.py", line 304, in write self.stream.write(data) File "/usr/lib/python2.5/site-packages/BitTorrent/__init__.py", line 140, in write StringIO.write(self, lines[-1]) AttributeError: 'NoneType' object has no attribute 'write' ############### Well, I guess not. [darwinhwebb@Jovette-14 /]$ bittorrent >>> unable to setrlimit not allowed to raise maximum limit GTK Accessibility Module initialized Exception in thread bittorrent:263 in <module>: threading.Thread(target=init_core, args=(mainloop,)).start(): Traceback (most recent call last): File "/usr/bin/bittorrent", line 263, in <module> threading.Thread(target=init_core, args=(mainloop,)).start() File "/usr/bin/bittorrent", line 215, in init_core init_torrents=False) File "/usr/lib/python2.5/site-packages/BitTorrent/MultiTorrent.py", line 167, in __init__ self._restore_state(init_torrents) File "/usr/lib/python2.5/site-packages/BitTorrent/MultiTorrent.py", line 823, in _restore_state t = decode_line(line) File "/usr/lib/python2.5/site-packages/BitTorrent/MultiTorrent.py", line 758, in decode_line t.working_path = t.working_path.decode('utf-8') File "/usr/lib/python2.5/site-packages/BitTorrent/Torrent.py", line 268, in _set_working_path self.config['working_path'] = value File "/usr/lib/python2.5/site-packages/BitTorrent/prefs.py", line 50, in __setitem__ isinstance(value, str), "'%s' is not str" % option AssertionError: 'working_path' is not str non-daemon threads not shutting down in a timely fashion: <StackThread(disk_thread-1, started)> <StackThread(disk_thread-2, started)> <StackThread(disk_thread-3, started)> You have no chance to survive make your time. Killed [darwinhwebb@Jovette-14 /]$
The compat-* packages are intended to be installed alongside the main wx* packages; you shouldn't need any fancy rpm options such as --oldpackage to get them installed. Some of the compat-* packages have dependencies on the main wx* packages because there are some files required by the compat-* packages that would have the same names as the files in the main wx* packages and hence would cause conflicts if both packages included them. So the alternative way is to not include those files in the compat-* packages and require the main packages instead. The ideal way to progress this bug forward would be for the underlying problem (which looks likely to be in wxGTK - see Bug #225043) to be fixed. However, if that doesn't happen, it seems that a workaround of providing compat-wx* packages will probably work. I will need to add a README.Fedora to the bittorrent package to tell people to remove their ~/.bittorrent file/directory if upgrading from an older version than 4.20.0. If we eventually go with the compat-* package workaround, I will add appropriate dependencies to the bittorrent package so that the correct packages (compat-wxPython26, compat-wxGTK26, and compat-wxGTK26-gl) get pulled in. Not sure about the crash on exit; I'm not seeing that here. It looks very much like the problem with an old ~/.bittorrent directory though that Sander reported in Comment #7. Are you sure you don't have one? ls -ld ~/.bit*
Hi Paul, I tried again with my regular username. I deleted the .bittorrent file. The progam started and initialized. I clicked on everything and it didn't crash but here are some things I found. 1. The Info (default tab) somethimes disappeared while a torrent was running. 2. The peers list - schroll bar is jittery and changes size and shape (unusable at times). 3. The message area at the bottopm right is too short. Hides critical parts of messages. 4. FAQ - does not work, does not exist or starts a web page. 5. I was able to start the program only after suppling several parms for DIR's and max upload. Even after this the Bittorrent Downloads folder was created on the Desktop. The program should not create any DIR paths until after opening and it should popup a first time settings for this stuff. I now have PATHS in may places. So to Compat or not to Compat. I think it need more work so if the wx coders can't commit to fixes within 10-12 days I would pull 5.0.5 out of extras and put 4.4.x back in so that the FC7T2 will have a working BT. The coders can come back with a better version and then you or packager can mess with it in post FC7T2 - T3 time. And in FC6-test. Thats MO. thanks for the the effort, Darwin
*** Bug 229507 has been marked as a duplicate of this bug. ***
Given that there is no sign of a fix for this coming any time soon (5.0.6 has some changes in logging but it still segfaults), I propose to revert development to 4.4.x until such time as the GUI works with the version of wx in development. A compat-WXGTK26 package has just appeared in Extras but the wxPython maintainer has doubts about the merits of a compat-wxPython26 package (see http://www.redhat.com/archives/fedora-maintainers/2007-February/msg00633.html) so I don't think the compat- route is the way to go. I'm also inclined not to use a epoch bump for the downgrade. Whilst this means that current rawhide users of bittorrent will need to downgrade manually, it does at least save us from needing an epoch in the package for the rest of eternity. Any other suggestions? If not, I'll try to get the downgrade done early next week.
Yep! revert rawhide back to 4.4.x please ... shame the new gui looked great before it segfaulted.
bittorrent-4.4.0-4.fc7 is now on download.fedora.redhat.com and should be on the mirrors within a day. Remember that a manual downgrade will be needed as there has been no epoch used.
I wonder if the problem is any better now that 225043 is fixed.
err nope same problems here with: bittorrent-5.0.7-1.CF.fc7 bittorrent-gui-5.0.7-1.CF.fc7 wxPython-2.8.3.0-1.fc7 wxGTK-2.8.3-2.fc7
Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
Given that upstream has gone closed source with version 6.x and nobody appears to be maintaining a fork of a 5.x open source version, I think there's little chance of this ever getting fixed, and so Fedora is going to be stuck with 4.4.0 indefinitely. I'm going to close this bug CANTFIX; if anyone wants to do the work of fixing this (effectively starting a fork of 5.x), I'll happily reopen this.