Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

New {lib,r}torrent released. As to libtorrent there's no change (that I know
of) in the build process, rtorrent now has the optional xmlrcp support, and the
bug 151221 is not a case in this version, so the flag -O2 -> -O3 replacement
becomes obsolete.

Created an attachment (id=122724) [details]
Proposed ebuild.

Reference for release
http://rakshasa.no/pipermail/libtorrent-devel/2007-June/001180.html

Compiles fine and (seems to) work fine for me on amd64 - both the new rtorrent
script and the renamed libtorrent.

From http://libtorrent.rakshasa.no/wiki/RTorrentXMLRPCGuide:
"What you need:

    * http://python.ca/scgi/ for Apache, Lighttpd should have this built-in.
    * http://xmlrpc-c.sourceforge.net/ 1.00 or later, 1.07 or later for 64bit
integer support.
    * rtorrent 0.7.5 or later. "

So, I think we should make something like
xmlrpc? (
        !amd64? (>=dev-libs/xmlrpc-c-1.00)
        amd64? (>=dev-libs/xmlrpc-c-1.007)
)

with RDEPEND.

Also, I suggest add some note about scgi.

Sorry, if I'm not right.

PS: both rtorrent 0.7.5 & libtorrent 0.11.5 forks fine for me (x86).
xmlprc support not yet tested

rtorrent 0.7.6 & libtorrent 0.11.6 out now.

The ebuilds are missing econf $(use_enable ipv6).

rtorrent 0.7.7 and libtorrent 0.11.7 are out now.

not as stable upstream versions.

Stable Release

    * libtorrent-0.11.6.tar.gz
    * rtorrent-0.7.6.tar.gz 

Unstable Release

Renamed all commands from e.g "get_d_*" to "d.get_*". Removed support for
appending multiple arguments to a 'schedule' command, it must now be quoted,
e.g 'schedule=foo,5,5,"print=foo,bar"'. Remember to update your rc file.

    * libtorrent-0.11.7.tar.gz
    * rtorrent-0.7.7.tar.gz

rtorrent 0.7.6 (attached ebuild) + libtorrent 0.11.6 (renamed ebuild)
work fine here on amd64. Would be nice to see this update in portage.

> The ebuilds are missing econf $(use_enable ipv6).
Well, viewing the code proves that INET6 support introduces almost no overhead,
so as there's no problems (?) with it enabled by default, IMO it should be left
as is. 

> amd64? (>=dev-libs/xmlrpc-c-1.07)
Sure, when I was modifing the ebuild I wasn't aware of it.

> I suggest add some note about scgi.
Most certanly yes. Current one provides info like `rtorrent now supports a
configuration file', so it is indeed outdated.

rtorrent in tree is at 0.7.8..

From rtorrent-0.7.8.ebuild: `--disable-xmlrpc-c: I want to keep it disabled
while >=dev-libs/xmlrpc-c-1.07 is masked'.  Supposedly that version is needed
for amd64, so `amd64? (>=dev-libs/xmlrpc-c-1.07)', or no amd64 KEYWORD at all
might suffice. Anyways good something has moved.

For what it's worth, I have been using the ebuild attached to this bug (renamed
for rtorrent-0.7.9) in conjunction with dev-libs/xmlrpc-c-1.06.09 on a amd64
machine for over a week now and everything has worked fine.

So, I am skeptical about a requirement of >=dev-libs/xmlrpc-c-1.07 for the
amd64 architecture as I have been making use of the xmlrpc interface constantly
(via wTorrent[1]) and it hasn't failed me yet.

[1] http://canbruixa.homelinux.net/wt/

Further digging shows that 64 integer support has nothing to do with arch. 
1.07 is needed for 64 bit results.  Therefor output for torrents with size
bigger than 2^31-1 bytes (approx. 2.1GB) is wrong/false with <1.07.  I am not
sure if that's the developer's reasoning to disable the feature completly.

Regardless of which xmlrpc-c version is needed for 64bit, could those of us not
running 64bit get the xmlrpc support?

I would suggest using a USE flag for xmlrpc, and then require the correct
version of xmlrpc-c for the architecture you're running on.

I can at least confirm that xmlrpc-c < 1.07 doesn't do 64bit integers onn 64bit
archs. I'm in that case and I get (signed) numbers wrapped at 2G to -2G when
using rtgui to manage my rtorrent through xmlrpc-c-1.06.09.
It should really be independent from the arch.

Err.. is there something we still need to change for rtorrent-0.8.2.ebuild ?

The xmlrpc-c issue is independent from rtorrent, and the misaligned accesses on
HPPA (and possibly other 64bit archs) aren't, as far as I know, anything that
could be solved in the ebuild but needs upstream attention.
So nothing to be done in the ebuild as far as I know.

After upgrading to:
 * dev-libs/xmlrpc-c-1.14.07
 * net-libs/libtorrent-0.12.2-r2
 * net-p2p/rtorrent-0.8.2-r2

everything is working fine on HPPA. It even shows correct file sizes in rtGui
(a web interface working through xmlrpc - see bug #182816)

(In reply to comment #19)
> (see bug #182816)
Please ignore the circular reference :)

rtorrent-0.8.2-r3 has xmlrpc support. Unaligned accesses adressed also. If you
use xmlrpc-c-1.14.07 (Which I will promptly make multlib-strict), you will get
64-bit integer support. Closing.