I propose to retire bittorrent (the original python client) for the reasons outlined below. If anyone's interested in taking it over instead, please apply on the package database and I'll transfer ownership. Think carefully before you act though!
Dead Upstream: ============== Well, not actually dead but upstream has gone closed-source as of version 6 so it's effectively dead.
Old Version: ============ Upstream's last open-source release (code dump really) was 5.3 (http://download.bittorrent.com/dl/), which was little more than a GPL re-licensing of 5.2.2 and a dump of upstream VCS content. Fedora has been stuck with 4.4.0 though with its PyGTK GUI because the "new" GUI in version 5 was a rewrite with wxGTK but it didn't work with wxGTK > 2.6 (http://bugzilla.redhat.com/223623) and so was unusable in Fedora.
I believe Mandriva "solved" this problem by having transmission obsolete bittorrent-gui and just shipping the console version.
Open Bugs: ========== http://bugzilla.redhat.com/189072 (bittorrent doesn't die gracefully) http://bugzilla.redhat.com/189295 (bittorrent is not utf-8 aware) http://bugzilla.redhat.com/237254 (translations not working since python 2.4) http://bugzilla.redhat.com/246879 (LSB-ize initscripts) http://bugzilla.redhat.com/489810 (bittorrent stops seeding files, even when "seed indefinitely" is checked) http://bugzilla.redhat.com/630569 (traceback due to argument parsing error) http://bugzilla.redhat.com/678710 (crash due to not running via provided initscript) http://bugzilla.redhat.com/707637 (RFE upgrade to 5.x)
Some of these are probably quite easily fixed by someone that knows their python and is willing to dive into the code but they would have to be prepared to the de-facto new upstream maintainer if they wanted to take it on.
Doesn't Obey Protocol: ====================== The bittorrent client is actually blocked on at least one major site due to violating the protocol and hammering the tracker with announcements: http://wiki.dimeadozen.org/index.php/Mainline
I propose to retire bittorrent (the original python client) for the reasons outlined below. If anyone's interested in taking it over instead, please apply on the package database and I'll transfer ownership. Think carefully before you act though!
Dead Upstream:
Well, not actually dead but upstream has gone closed-source as of version 6 so it's effectively dead.
Old Version:
Upstream's last open-source release (code dump really) was 5.3 (http://download.bittorrent.com/dl/), which was little more than a GPL re-licensing of 5.2.2 and a dump of upstream VCS content. Fedora has been stuck with 4.4.0 though with its PyGTK GUI because the "new" GUI in version 5 was a rewrite with wxGTK but it didn't work with wxGTK > 2.6 (http://bugzilla.redhat.com/223623) and so was unusable in Fedora.
I believe Mandriva "solved" this problem by having transmission obsolete bittorrent-gui and just shipping the console version.
Open Bugs:
http://bugzilla.redhat.com/189072 (bittorrent doesn't die gracefully) http://bugzilla.redhat.com/189295 (bittorrent is not utf-8 aware) http://bugzilla.redhat.com/237254 (translations not working since python 2.4) http://bugzilla.redhat.com/246879 (LSB-ize initscripts) http://bugzilla.redhat.com/489810 (bittorrent stops seeding files, even when "seed indefinitely" is checked) http://bugzilla.redhat.com/630569 (traceback due to argument parsing error) http://bugzilla.redhat.com/678710 (crash due to not running via provided initscript) http://bugzilla.redhat.com/707637 (RFE upgrade to 5.x)
Some of these are probably quite easily fixed by someone that knows their python and is willing to dive into the code but they would have to be prepared to the de-facto new upstream maintainer if they wanted to take it on.
Doesn't Obey Protocol:
The bittorrent client is actually blocked on at least one major site due to violating the protocol and hammering the tracker with announcements: http://wiki.dimeadozen.org/index.php/Mainline
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
My only concern is that there be a command-line replacement available. I currently fetch my ISOs with bittorrent-curses and screen. Can someone with experience with any of them offer a recommendation? Python, C and C++ clients especially. I've searched, but there are many out there.
-J
Jon Ciesla writes:
My only concern is that there be a command-line replacement available. I currently fetch my ISOs with bittorrent-curses and screen. Can someone with experience with any of them offer a recommendation?
transmission-cli works for me.
transmission should be sufficient to replace bittorrent.
On Wed, Jun 15, 2011 at 2:37 PM, Jon Ciesla limb@jcomserv.net wrote:
My only concern is that there be a command-line replacement available. I currently fetch my ISOs with bittorrent-curses and screen. Can someone with experience with any of them offer a recommendation? Python, C and C++ clients especially. I've searched, but there are many out there.
transmission-cli should do the job
Tim
On 06/15/2011 01:37 PM, Jon Ciesla wrote:
I propose to retire bittorrent (the original python client) for the reasons outlined below. If anyone's interested in taking it over instead, please apply on the package database and I'll transfer ownership. Think carefully before you act though!
Dead Upstream:
Well, not actually dead but upstream has gone closed-source as of version 6 so it's effectively dead.
Old Version:
Upstream's last open-source release (code dump really) was 5.3 (http://download.bittorrent.com/dl/), which was little more than a GPL re-licensing of 5.2.2 and a dump of upstream VCS content. Fedora has been stuck with 4.4.0 though with its PyGTK GUI because the "new" GUI in version 5 was a rewrite with wxGTK but it didn't work with wxGTK> 2.6 (http://bugzilla.redhat.com/223623) and so was unusable in Fedora.
I believe Mandriva "solved" this problem by having transmission obsolete bittorrent-gui and just shipping the console version.
Open Bugs:
http://bugzilla.redhat.com/189072 (bittorrent doesn't die gracefully) http://bugzilla.redhat.com/189295 (bittorrent is not utf-8 aware) http://bugzilla.redhat.com/237254 (translations not working since python 2.4) http://bugzilla.redhat.com/246879 (LSB-ize initscripts) http://bugzilla.redhat.com/489810 (bittorrent stops seeding files, even when "seed indefinitely" is checked) http://bugzilla.redhat.com/630569 (traceback due to argument parsing error) http://bugzilla.redhat.com/678710 (crash due to not running via provided initscript) http://bugzilla.redhat.com/707637 (RFE upgrade to 5.x)
Some of these are probably quite easily fixed by someone that knows their python and is willing to dive into the code but they would have to be prepared to the de-facto new upstream maintainer if they wanted to take it on.
Doesn't Obey Protocol:
The bittorrent client is actually blocked on at least one major site due to violating the protocol and hammering the tracker with announcements: http://wiki.dimeadozen.org/index.php/Mainline
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
My only concern is that there be a command-line replacement available. I currently fetch my ISOs with bittorrent-curses and screen. Can someone with experience with any of them offer a recommendation? Python, C and C++ clients especially. I've searched, but there are many out there.
I personally use rtorrent.
Paul.
On 06/15/2011 01:37 PM, Jon Ciesla wrote:
I propose to retire bittorrent (the original python client) for the reasons outlined below. If anyone's interested in taking it over instead, please apply on the package database and I'll transfer ownership. Think carefully before you act though!
Dead Upstream:
Well, not actually dead but upstream has gone closed-source as of version 6 so it's effectively dead.
Old Version:
Upstream's last open-source release (code dump really) was 5.3 (http://download.bittorrent.com/dl/), which was little more than a GPL re-licensing of 5.2.2 and a dump of upstream VCS content. Fedora has been stuck with 4.4.0 though with its PyGTK GUI because the "new" GUI in version 5 was a rewrite with wxGTK but it didn't work with wxGTK> 2.6 (http://bugzilla.redhat.com/223623) and so was unusable in Fedora.
I believe Mandriva "solved" this problem by having transmission obsolete bittorrent-gui and just shipping the console version.
Open Bugs:
http://bugzilla.redhat.com/189072 (bittorrent doesn't die gracefully) http://bugzilla.redhat.com/189295 (bittorrent is not utf-8 aware) http://bugzilla.redhat.com/237254 (translations not working since python 2.4) http://bugzilla.redhat.com/246879 (LSB-ize initscripts) http://bugzilla.redhat.com/489810 (bittorrent stops seeding files, even when "seed indefinitely" is checked) http://bugzilla.redhat.com/630569 (traceback due to argument parsing error) http://bugzilla.redhat.com/678710 (crash due to not running via provided initscript) http://bugzilla.redhat.com/707637 (RFE upgrade to 5.x)
Some of these are probably quite easily fixed by someone that knows their python and is willing to dive into the code but they would have to be prepared to the de-facto new upstream maintainer if they wanted to take it on.
Doesn't Obey Protocol:
The bittorrent client is actually blocked on at least one major site due to violating the protocol and hammering the tracker with announcements: http://wiki.dimeadozen.org/index.php/Mainline
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
My only concern is that there be a command-line replacement available. I currently fetch my ISOs with bittorrent-curses and screen. Can someone with experience with any of them offer a recommendation? Python, C and C++ clients especially. I've searched, but there are many out there.
I personally use rtorrent.
Paul.
Excellent, I'll check out rtorrent and transmission-cli. Thanks all, carry on!
-J
15.06.2011, 21:37, "Jon Ciesla" limb@jcomserv.net:
My only concern is that there be a command-line replacement available. I currently fetch my ISOs with bittorrent-curses and screen. Can someone with experience with any of them offer a recommendation? Python, C and C++ clients especially. I've searched, but there are many out there.
I think you should look at deluge-console for there is also a daemon that runs separately, supporting tasks priority, queueing, automatic torrent management, and they've got a nice bandwidth tweaking how-to for it [1].
[1] http://dev.deluge-torrent.org/wiki/UserGuide/BandwidthTweaking
15.06.2011, 21:37, "Jon Ciesla" limb@jcomserv.net:
My only concern is that there be a command-line replacement available. I currently fetch my ISOs with bittorrent-curses and screen. Can someone with experience with any of them offer a recommendation? Python, C and C++ clients especially. I've searched, but there are many out there.
I think you should look at deluge-console for there is also a daemon that runs separately, supporting tasks priority, queueing, automatic torrent management, and they've got a nice bandwidth tweaking how-to for it [1].
[1] http://dev.deluge-torrent.org/wiki/UserGuide/BandwidthTweaking
<Spock>Fascinating.</Spock>
Thanks!
-J
-- Best regards, Misha Shnurapet, Fedora Project Contributor Email: shnurapet AT fedoraproject.org, IRC: misha on freenode https://fedoraproject.org/wiki/shnurapet, GPG: 00217306 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Wednesday, June 15, 2011 07:12:56 AM Paul Howarth wrote:
I propose to retire bittorrent (the original python client) for the reasons outlined below. If anyone's interested in taking it over instead, please apply on the package database and I'll transfer ownership. Think carefully before you act though!
Dead Upstream:
Well, not actually dead but upstream has gone closed-source as of version 6 so it's effectively dead.
we use it as the official torrent server for torrent.fedoraproject.org we have not found any other servers that work totally for us. if we are getting rid of it we should also look as using something else for the torrents we provide.
A nice thing to have is something that we can use with ipv6 and ipv4, the server that torrent.fp.o is on has both
Dennis
On Wed, 2011-06-15 at 21:08 -0500, Dennis Gilmore wrote:
On Wednesday, June 15, 2011 07:12:56 AM Paul Howarth wrote:
I propose to retire bittorrent (the original python client) for the reasons outlined below. If anyone's interested in taking it over instead, please apply on the package database and I'll transfer ownership. Think carefully before you act though!
Dead Upstream:
Well, not actually dead but upstream has gone closed-source as of version 6 so it's effectively dead.
we use it as the official torrent server for torrent.fedoraproject.org we have not found any other servers that work totally for us. if we are getting rid of it we should also look as using something else for the torrents we provide.
A nice thing to have is something that we can use with ipv6 and ipv4, the server that torrent.fp.o is on has both
Heck, I'd be willing to accept ANY bittorrent server that can be both tracker and primary seed and doesn't require a special apache module to do it.
The biggest virtue of the old bittorrent client is that it is simple, stand alone and while not fancy, it is straightforward to understand.
-sv
On Wed, Jun 15, 2011 at 9:55 PM, seth vidal skvidal@fedoraproject.org wrote:
Heck, I'd be willing to accept ANY bittorrent server that can be both tracker and primary seed and doesn't require a special apache module to do it.
The biggest virtue of the old bittorrent client is that it is simple, stand alone and while not fancy, it is straightforward to understand.
Why not look into using Web/HTTP seeding rather than running a client for the initial seed? The only downsides that I know of so far:
1) Not supported in rtorrent 2) Transmission doesn't apply any bandwidth limits to Web/HTTP seeds
On Sat, 2011-06-25 at 22:23 -0500, Jeffrey Ollie wrote:
On Wed, Jun 15, 2011 at 9:55 PM, seth vidal skvidal@fedoraproject.org wrote:
Heck, I'd be willing to accept ANY bittorrent server that can be both tracker and primary seed and doesn't require a special apache module to do it.
The biggest virtue of the old bittorrent client is that it is simple, stand alone and while not fancy, it is straightforward to understand.
Why not look into using Web/HTTP seeding rather than running a client for the initial seed? The only downsides that I know of so far:
- Not supported in rtorrent
- Transmission doesn't apply any bandwidth limits to Web/HTTP seeds
Following up late on this, sorry.
The seed is less of an issue than the tracker. Is there a solution to that? -sv
On 06/15/2011 09:55 PM, seth vidal wrote:
Heck, I'd be willing to accept ANY bittorrent server that can be both tracker and primary seed and doesn't require a special apache module to do it.
Late to the party with this response but here it is anyway.
I'd suggest switching to magnet links. They would negate the need for a tracker and the need for serving a .torrent file.
Without a need for a tracker server the deluge-web client might work for you as a primary seed. If that isn't good enough you could whip out something custom for Fedora to talk to the deluge-daemon to control it.
On Sun, 2011-06-26 at 00:22 -0500, Michael Cronenworth wrote:
On 06/15/2011 09:55 PM, seth vidal wrote:
Heck, I'd be willing to accept ANY bittorrent server that can be both tracker and primary seed and doesn't require a special apache module to do it.
Late to the party with this response but here it is anyway.
I'd suggest switching to magnet links. They would negate the need for a tracker and the need for serving a .torrent file.
googling around gets me info on how magnet links work. Now, what tools do we have in fedora to generate them and the Distributed Hash Tables.
I'd be pleased to dump out all of the special needs for the torrent server.
-sv
On 07/14/2011 01:07 PM, seth vidal wrote:
googling around gets me info on how magnet links work. Now, what tools do we have in fedora to generate them and the Distributed Hash Tables.
Sorry for the delay again.
There's no tool required. As long as you know the hash of the torrent you can make a magnet link.
Example: Fedora 15 DVD infohash: c221142c59abb4fcbffc4da1e2a19719e35a9217 Magnet link: magnet:?xt=urn:btih:c221142c59abb4fcbffc4da1e2a19719e35a9217
That's it! Of course, you can get fancy and add the name of the torrent, etc. if you wish, too.
Feel free to try it now by adding it to your torrent downloader that supports magnet links.
On Wednesday, June 15, 2011 07:12:56 AM Paul Howarth wrote:
I propose to retire bittorrent (the original python client) for the reasons outlined below. If anyone's interested in taking it over instead, please apply on the package database and I'll transfer ownership. Think carefully before you act though!
Dead Upstream:
Well, not actually dead but upstream has gone closed-source as of version 6 so it's effectively dead.
we use it as the official torrent server for torrent.fedoraproject.org we have not found any other servers that work totally for us. if we are getting rid of it we should also look as using something else for the torrents we provide.
A nice thing to have is something that we can use with ipv6 and ipv4, the server that torrent.fp.o is on has both
I'm not sure that's a nice to have, I'd think that that would be a must, so we don't have to change again later.
-J
Dennis
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Wed, 2011-06-15 at 13:12 +0100, Paul Howarth wrote:
I believe Mandriva "solved" this problem by having transmission obsolete bittorrent-gui and just shipping the console version.
Yup. We did. Exactly nobody complained. :)
I have now retired bittorrent in git, pkgdb and comps, and have filed ticket https://fedorahosted.org/rel-eng/ticket/4783 to have it blocked in koji since there were no real objections.
Anyone that would like to breathe new life into it is welcome to take it.
Paul.
-
Adam Williamson -
Dennis Gilmore -
Jeffrey Ollie -
Jon Ciesla -
Michael Cronenworth -
Misha Shnurapet -
Paul Howarth -
Sam Varshavchik -
Seth Vidal -
Tim Lauridsen