Bug#490277: rtorrent: IPv6 support would be nice
Package: rtorrent
Version: 0.9.2-1
Followup-For: Bug #490277
Bug does not resolved.
~# netstat -nap | grep tor
tcp0 0 0.0.0.0:68830.0.0.0:*
LISTEN 24684/rtorrent
~# ip -6 a l eth0
2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qlen 1000
inet6 2001:67c:2158:{MY_SUBNET}:13/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::213:d4ff:fea5:5390/64 scope link
valid_lft forever preferred_lft forever
IPv6 connection works fine, but rtorrent don't bind ipv6 socket.
-- System Information:
Debian Release: 7.1
APT prefers stable
APT policy: (650, 'stable'), (560, 'testing'), (500,
'stable-updates'), (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages rtorrent depends on:
ii libc6 2.13-38
ii libcurl37.26.0-1+wheezy3
ii libgcc1 1:4.7.2-5
ii libncursesw55.9-10
ii libsigc++-2.0-0c2a 2.2.10-0.2
ii libstdc++6 4.7.2-5
ii libtinfo5 5.9-10
ii libtorrent140.13.2-1
ii libxmlrpc-core-c3 1.16.33-3.2
rtorrent recommends no packages.
Versions of packages rtorrent suggests:
ii screen 4.1.0~20120320gitdb59704-7
-- no debconf information
--
Best regards,
Mikhail
-
WWW: http://www.antmix.ru/
XMPP: ant...@stopicq.ru
signature.asc
Description: OpenPGP digital signature
Bug#490277: rtorrent: IPv6 support would be nice
Hi.
Sorry for the late reply, but things are quite hectic here.
2011/9/30 Steinar H. Gunderson sgunder...@bigfoot.com:
On Fri, Sep 30, 2011 at 02:50:22PM -0300, Rogério Brito wrote:
(It may be truly trivial, but I have not see the cause of the
compilation errors).
Are there actually compilation errors here? If so, can anybody point me to
them?
Well, as I don't have the right to upload to Debian, I uploaded to a
PPA of mine in launchpad and this is the same error that I get when I
compile with a pure Debian system:
https://launchpad.net/~rbrito/+archive/ppa/+build/2838630/+files/buildlog_ubuntu-oneiric-amd64.libtorrent_0.12.9-2_FAILEDTOBUILD.txt.gz
From a very quick look at it, it seems that g++ is complaining about a
constructor that seems fine to me...
Suggestions?
Regards,
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#490277: rtorrent: IPv6 support would be nice
On Wed, Oct 12, 2011 at 10:42:13AM -0300, Rogério Brito wrote: From a very quick look at it, it seems that g++ is complaining about a constructor that seems fine to me... It's complaining about the lack of definition of in6_addr (and later rak::socket_address_inet6). You could add the right #includes for it (probably rak/socket_address.h), but since SocketAddressCompact has been moved to a different header file, probably so should SocketAddressCompact6; the two should live together. I have to say that if you're the Debian maintainer of a C++ package, you should be able to diagnose g++ errors like this yourself, though :-) /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#490277: rtorrent: IPv6 support would be nice
On Thu, Sep 29, 2011 at 08:55:14PM -0300, Rogério Brito wrote: Hi, Michael. On Sep 30 2011, Michael Tokarev wrote: So this change, IMHO, makes more bad than good. I had to revert this patch in local package in order to make it actually work with v6 disabled on the system. I will upload a new version of the combo libtorrent/rtorrent and they will have the IPv6 support removed for the reason you mention and for breaking compilation. I think I would rather see a package that only works on hosts that have ipv6 loaded than no ipv6 support at all. And I have a feeling I'm not the only one. It should probably be easy to change the patch to do the right thing. Steinar can you take a look at that? I'm *really* short on time to fix the compilation (which may be something trivial). It also seem that IPv6 has problems with the 3.x kernels as reported in other bugs. Which compilation issues are you talking about? I can't find any open bug report? So linux 3.x thing you mean is #635700. Which also seems to be because the kernel doesn't have IPv6 support, and the code is then trying to do the wrong thing. I think that I will wait for upstream to integrate IPv6 support. But I'm using rtorrent less and less, as my primary bittorrent client is, right now, qbittorrent. Please consider an request for adoption or orphaning the package if you feel you don't want to maintain it anymore. Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#490277: rtorrent: IPv6 support would be nice
Hi, Kurt.
Thank you very much for your feedback. It is really appreciated.
2011/9/30 Kurt Roeckx k...@roeckx.be:
On Thu, Sep 29, 2011 at 08:55:14PM -0300, Rogério Brito wrote:
I will upload a new version of the combo libtorrent/rtorrent and they will
have the IPv6 support removed for the reason you mention and for breaking
compilation.
I think I would rather see a package that only works on hosts that
have ipv6 loaded than no ipv6 support at all. And I have a
feeling I'm not the only one.
OK, the package provided by upstream is not flexible enough, in the
sense that it doesn't have IPv6 supported and that others have
implemented patches, but are not supporting it (well, Steinar did take
the trouble of updating some times), but, right now, libtorrent
doesn't compile with the patch applied.
(It may be truly trivial, but I have not see the cause of the
compilation errors).
It should probably be easy to change the patch to do the right
thing. Steinar can you take a look at that?
Hopefully, if he does, I can keep it updated to Debian. But with one
catch: as I am only a lowly Debian Maintainer, I can't upload a new
version of libtorrent to the main archive by myself, as upstream has
changed the SONAME to libtorrent14 and DM's can't upload such a
package.
Having my hands tied this way is a major bummer.
Which compilation issues are you talking about? I can't find
any open bug report?
Indeed, you can't. They are not present with the versions in Debian,
but they appeare with libtorrent that I would upload + Steinar's IPv6
patch. I only discovered that yesterday, as I wanted to upload a new
version of rtorrent/libtorrent to the archive.
But:
http://identi.ca/notice/84342327
So linux 3.x thing you mean is #635700.
Yes, that's the one.
Which also seems to be because the kernel doesn't have IPv6 support, and the
code
is then trying to do the wrong thing.
Yes, but we lack a fix and upstream is not really responsive:
http://thread.gmane.org/gmane.linux.network/199373
But I'm using rtorrent less and less, as my primary bittorrent client is,
right now, qbittorrent.
Please consider an request for adoption or orphaning the package
if you feel you don't want to maintain it anymore.
I'm not exactly sure if we need to orphan the package, as it 3 current
maintainers: 2 DDs (ghostbar and unera), and 1 DM (me).
I told ghostbar that I planned the past upload of libtorrent/rtorrent
to be my last ones of this package, but as he was busy with school, I
waited so that the package should have at least some support.
So, summarizing the various points here:
* Despite me having a half prepared upload in our git trees (which,
BTW, I am already using myself), I can't upload it... It may have been
past the time for me to become a DD, it seems.
* Upstream has not given many signs of life and the project seems moribund.
* We have patches from the community, but they are not integrated in
the main project, which means that they are very likely to break from
update from update, unless the project is forked.
* The other maintainers of the package seem to be busy.
Further feedback is appreciated.
Regards,
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#490277: rtorrent: IPv6 support would be nice
On 30.09.2011 21:50, Rogério Brito wrote: Hi, Kurt. Thank you very much for your feedback. It is really appreciated. 2011/9/30 Kurt Roeckx k...@roeckx.be: On Thu, Sep 29, 2011 at 08:55:14PM -0300, Rogério Brito wrote: I will upload a new version of the combo libtorrent/rtorrent and they will have the IPv6 support removed for the reason you mention and for breaking compilation. I think I would rather see a package that only works on hosts that have ipv6 loaded than no ipv6 support at all. And I have a feeling I'm not the only one. I would rather see a package which works in all cases. Uploading something that works just by a chance is wrong, and arguing which is better to break these or those installs is not a Debian Way. Just IMHO anyway. OK, the package provided by upstream is not flexible enough, in the sense that it doesn't have IPv6 supported and that others have implemented patches, but are not supporting it (well, Steinar did take the trouble of updating some times), but, right now, libtorrent doesn't compile with the patch applied. (It may be truly trivial, but I have not see the cause of the compilation errors). Can you show me the patches and versions you're trying to build? It should probably be easy to change the patch to do the right thing. Steinar can you take a look at that? Hopefully, if he does, I can keep it updated to Debian. But with one catch: as I am only a lowly Debian Maintainer, I can't upload a new version of libtorrent to the main archive by myself, as upstream has changed the SONAME to libtorrent14 and DM's can't upload such a package. Having my hands tied this way is a major bummer. Which compilation issues are you talking about? I can't find any open bug report? Indeed, you can't. They are not present with the versions in Debian, but they appeare with libtorrent that I would upload + Steinar's IPv6 patch. I only discovered that yesterday, as I wanted to upload a new version of rtorrent/libtorrent to the archive. But: http://identi.ca/notice/84342327 That one is easy, if we will find a solution to the problems I can sponsor the upload for you (I'm a DD). Your first upload was done by a sponsor too ;) So linux 3.x thing you mean is #635700. Yes, that's the one. Note that it didn't work before that change anyway, at least with the IPv6 patch applied. It needs more careful changes - as far as i can see, libtorrent is trying to open v6 or v4 socket without telling that to rtorrent, which tries to bind some addresss to it. The two needs to be coordinated obviously. Which also seems to be because the kernel doesn't have IPv6 support, and the code is then trying to do the wrong thing. Yes, but we lack a fix and upstream is not really responsive: http://thread.gmane.org/gmane.linux.network/199373 But I'm using rtorrent less and less, as my primary bittorrent client is, right now, qbittorrent. Please consider an request for adoption or orphaning the package if you feel you don't want to maintain it anymore. I'm not exactly sure if we need to orphan the package, as it 3 current maintainers: 2 DDs (ghostbar and unera), and 1 DM (me). Especially as the package has 2 more maintainers. I told ghostbar that I planned the past upload of libtorrent/rtorrent to be my last ones of this package, but as he was busy with school, I waited so that the package should have at least some support. So, summarizing the various points here: * Despite me having a half prepared upload in our git trees (which, BTW, I am already using myself), I can't upload it... It may have been past the time for me to become a DD, it seems. * Upstream has not given many signs of life and the project seems moribund. * We have patches from the community, but they are not integrated in the main project, which means that they are very likely to break from update from update, unless the project is forked. * The other maintainers of the package seem to be busy. Further feedback is appreciated. The first step - just in my opinion anyway - is to understand what's up with the upstream. The fact that the project shows no signs of life is not good... :( Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#490277: rtorrent: IPv6 support would be nice
On Fri, Sep 30, 2011 at 02:50:22PM -0300, Rogério Brito wrote: (It may be truly trivial, but I have not see the cause of the compilation errors). Are there actually compilation errors here? If so, can anybody point me to them? The error in #635700 is easy enough; if bind() to [::] fails, just try 0.0.0.0. Or keep track of whether the socket is AF_INET6 or AF_INET, and bind to [::] or 0.0.0.0 respectively. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#490277: rtorrent: IPv6 support would be nice
Apparently the fix breaks IPv4 support on kernels where v6 is
disabled. The resulting code does wrong thing:
socket(PF_INET6, SOCK_STREAM, IPPROTO_TCP) = -1 EAFNOSUPPORT (Address family
not supported by protocol)
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 5
fcntl64(5, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
setsockopt(5, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
bind(5, {sa_family=AF_INET6, sin6_port=htons(6974), inet_pton(AF_INET6, ::,
sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EAFNOSUPPORT
bind(5, {sa_family=AF_INET6, sin6_port=htons(6975), inet_pton(AF_INET6, ::,
sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EAFNOSUPPORT
bind(5, {sa_family=AF_INET6, sin6_port=htons(6976), inet_pton(AF_INET6, ::,
sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EAFNOSUPPORT
bind(5, {sa_family=AF_INET6, sin6_port=htons(6977), inet_pton(AF_INET6, ::,
sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EAFNOSUPPORT
bind(5, {sa_family=AF_INET6, sin6_port=htons(6978), inet_pton(AF_INET6, ::,
sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EAFNOSUPPORT
bind(5, {sa_family=AF_INET6, sin6_port=htons(6979), inet_pton(AF_INET6, ::,
sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EAFNOSUPPORT
bind(5, {sa_family=AF_INET6, sin6_port=htons(6980), inet_pton(AF_INET6, ::,
sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EAFNOSUPPORT
bind(5, {sa_family=AF_INET6, sin6_port=htons(6981), inet_pton(AF_INET6, ::,
sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EAFNOSUPPORT
Or, on older kernel:
socket(PF_INET6, SOCK_STREAM, IPPROTO_TCP) = -1 EAFNOSUPPORT (Address family
not supported by protocol)
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 5
fcntl64(5, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
setsockopt(5, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
bind(5, {sa_family=AF_INET6, sin6_port=htons(38424), inet_pton(AF_INET6, ::,
sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINVAL (Invalid
argument)
Which is, obviosly, plain wrong.
So this change, IMHO, makes more bad than good.
I had to revert this patch in local package in order
to make it actually work with v6 disabled on the system.
Thanks,
/mjt
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#490277: rtorrent: IPv6 support would be nice
reopen 490277
quit
Hi, Michael.
On Sep 30 2011, Michael Tokarev wrote:
So this change, IMHO, makes more bad than good.
I had to revert this patch in local package in order
to make it actually work with v6 disabled on the system.
I will upload a new version of the combo libtorrent/rtorrent and they will
have the IPv6 support removed for the reason you mention and for breaking
compilation.
I'm *really* short on time to fix the compilation (which may be something
trivial). It also seem that IPv6 has problems with the 3.x kernels as
reported in other bugs.
I think that I will wait for upstream to integrate IPv6 support.
But I'm using rtorrent less and less, as my primary bittorrent client is,
right now, qbittorrent.
Regards,
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#490277: rtorrent: IPv6 support would be nice
tags 490277 + confirmed upstream thanks This bug has been reported upstream at: http://libtorrent.rakshasa.no/ticket/ Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#490277: rtorrent: IPv6 support would be nice
Package: rtorrent Version: 0.7.9-2+b1 Severity: wishlist Subject mostly says it all. :-) --- Drake Wilson -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (990, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24.2 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages rtorrent depends on: ii libc-ares2 1.5.2-2 library for asyncronous name resol ii libc6 2.7-12GNU C Library: Shared libraries ii libcomerr2 1.40.8-2 common error description library ii libcurl3 7.18.1-1+b1 Multi-protocol file transfer libra ii libgcc11:4.3.1-2 GCC support library ii libidn11 1.8-1 GNU libidn library, implementation ii libkrb53 1.6.dfsg.3-2 MIT Kerberos runtime libraries ii libldap-2.4-2 2.4.9-1 OpenLDAP libraries ii libncursesw5 5.6+20080614-1Shared libraries for terminal hand ii libsigc++-2.0-0c2a 2.0.18-2 type-safe Signal Framework for C++ ii libssh2-1 0.18-1SSH2 client-side library ii libssl0.9.80.9.8g-10.1 SSL shared libraries ii libstdc++6 4.3.1-2 The GNU Standard C++ Library v3 ii libtorrent10 0.11.9-1.1a C++ BitTorrent library ii libxmlrpc-c3 1.06.27-1 A lightweight RPC library based on ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime rtorrent recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
