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.