Description of problem: Seen in FC 7 T2 Version-Release number of selected component (if applicable): rpm bittorrent-5.0.5-2.fc7 How reproducible: Always Steps to Reproduce: bittorrent-curses --max_upload_rate 22 --save_in /home/stymar/fc7 \ --save_incomplete_in /home/stymar/fc7 \ http://torrent.fedoraproject.org/torrents/f7-test2-dvd-i386.torrent 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 $HOME/.bittorrent/incomplete/f7-test2-dvd-i386 Setting both --save_in and --save_incomplete_in to the target directory got past this problem. 2. Every time bittorrent-curses starts it generates the message: >>> 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. Actual results: Expected results: Behavior similar to FC6 Additional info:
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: 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.
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.