Red Hat Bugzilla – Bug 230878
bittorrent-curses does not show upload activity and produces setrlimit message
Last modified: 2008-04-09 05:48:28 EDT
Description of problem:
Seen in FC 7 T2
Version-Release number of selected component (if applicable):
How reproducible: Always
Steps to Reproduce:
bittorrent-curses --max_upload_rate 22 --save_in /home/stymar/fc7 \
--save_incomplete_in /home/stymar/fc7 \
I downloaded fc7t2 with my fc6 machine 3/1/2007
installed it on a test machine and it loaded fine.
Copied the bittorrent data over from the fc6
machine and planned to let it run as a seed for
a few days.
1. bittorrent-curses changed where it wants to
put the loaded files. In fc6 it put them
under the current directory. Added the
--save_in parameter, but that did not help
much. It said it was going to put the file
where expected, but instead of running as a
seed, it started downloading to
Setting both --save_in and --save_incomplete_in to
the target directory got past this problem.
2. Every time bittorrent-curses starts it generates
>>> unable to setrlimit not allowed to raise maximum limit
I am running this as a normal user.
This is not a problem on FC6
3. Even though I moved the port forwarding to the test
machine for ports 6881-6999, it never shows any uploading.
The fc6 machine behaves fine. Closer inspection using
netstat -a showed 119 established connections on port 6881
and the lights on my router shows a lot of data moving.
So seeding is actually working. It is just not showing up on
the curses display.
Behavior similar to FC6
Bittorrent in rawhide has already been downgraded back to 4.4.0 as announced on
fedora-devel-list, due to compatibility issues with wxPython 2.8. If you remove
the bittorrent packages and re-install bittorrent using yum, you'll get 4.4.0 back.
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:
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
As upstream has gone closed source with version 6.x and all version 5.x releases
are incompatible with the wxPython version in Fedora 7 onwards (Bug #223623),
it's highly unlikely that a version later than 4.4.x is ever going to appear in
Fedora and hence this problem won't be re-appearing.
Hence I'm going to close this bug.