Bug 230878 - bittorrent-curses does not show upload activity and produces setrlimit message
bittorrent-curses does not show upload activity and produces setrlimit message
Product: Fedora
Classification: Fedora
Component: bittorrent (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Paul Howarth
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-03-03 23:44 EST by Robert Styma
Modified: 2008-04-09 05:48 EDT (History)
1 user (show)

See Also:
Fixed In Version: 4.4.0-5.fc7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-04-09 05:48:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Robert Styma 2007-03-03 23:44:43 EST
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 \

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
    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 04:41:18 EST
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 19:37:25 EDT
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.
Comment 3 Paul Howarth 2008-04-09 05:48:28 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.