Bug 230878

Summary: bittorrent-curses does not show upload activity and produces setrlimit message
Product: [Fedora] Fedora Reporter: Robert Styma <stymar>
Component: bittorrentAssignee: Paul Howarth <paul>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: triage
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard: bzcl34nup
Fixed In Version: 4.4.0-5.fc7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-04-09 09:48:28 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Robert Styma 2007-03-04 04:44:43 UTC
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:

Comment 1 Paul Howarth 2007-03-04 09:41:18 UTC
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.

Comment 2 Bug Zapper 2008-04-03 23:37:25 UTC
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.

Comment 3 Paul Howarth 2008-04-09 09:48:28 UTC
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.