Subject mostly says it all. :-)
tags 490277 + confirmed upstream thanks This bug has been reported upstream at: http://libtorrent.rakshasa.no/ticket/1111 Jonathan
Hello I have had reports that ipv6 support is now OK in rtorrent. Can you please remove the --no-ipv6 switch and reupload the rtorrent package ? Regards
It was definitely not, but the upstream bug now has a patch. Debian may or may not want to be proactive and pull in the patch independently of upstream. /* Steinar */
We believe that the bug you reported is fixed in the latest version of
rtorrent, which is due to be installed in the Debian FTP archive:
rtorrent_0.8.7-4.debian.tar.gz
to main/r/rtorrent/rtorrent_0.8.7-4.debian.tar.gz
rtorrent_0.8.7-4.dsc
to main/r/rtorrent/rtorrent_0.8.7-4.dsc
rtorrent_0.8.7-4_i386.deb
to main/r/rtorrent/rtorrent_0.8.7-4_i386.deb
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 490277@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Rogério Brito <rbrito@ime.usp.br> (supplier of updated rtorrent package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)
Format: 1.8
Date: Sun, 27 Feb 2011 12:13:34 -0300
Source: rtorrent
Binary: rtorrent
Architecture: source i386
Version: 0.8.7-4
Distribution: unstable
Urgency: low
Maintainer: Jose Luis Rivas <ghostbar@debian.org>
Changed-By: Rogério Brito <rbrito@ime.usp.br>
Description:
rtorrent - ncurses BitTorrent client based on LibTorrent from rakshasa
Closes: 490277 563075 564525 615161
Changes:
rtorrent (0.8.7-4) unstable; urgency=low
.
* Upload to unstable.
* Add files to ignore for git's puposes.
* Don't remove the .pc directory as this confuses dpkg royally.
* Remove patches that are not relevant anymore.
* Leave the main tree unpatched to not confuse dpkg.
* Remove the removal of test/Makefile.
* Refresh debian/patches.
* Put a .patch extension on the patches in debian/patches.
* Build-depend on libxmlrpc-core-c3-dev instead of libxmlrpc-c3-dev.
Closes: #563075, #615161.
* Pass --parallel to dh, to enable parallel builds.
* Unapply patches after build
* Fix future FTBFS with ld.gold.
* Since we are rebuilding against a new librtorrent, this closes: #564525.
* Pass option --enable-ipv6 to configure. Closes: #490277.
Checksums-Sha1:
5f9af7c82dcd91a80b7ff8585ecd3cd68ea6ce8b 1393 rtorrent_0.8.7-4.dsc
c058ef4e89e018aadb2b8378cd660064034ad548 10242 rtorrent_0.8.7-4.debian.tar.gz
5d0c4417b795f9af99301f67dcc93c731ca54e24 430986 rtorrent_0.8.7-4_i386.deb
Checksums-Sha256:
43095ab60171b078c87a677f224eba20c03b3391eb2c927d481b29db5bb138ba 1393 rtorrent_0.8.7-4.dsc
86d5cc5859930831d3d134ccc7bb47528eb0e3a85c273245ff8aef39fdc15a26 10242 rtorrent_0.8.7-4.debian.tar.gz
233f6f589ed7b73f66df5e7dae7be022e83b2dd9eeb6c2acad5404ce7e3b681e 430986 rtorrent_0.8.7-4_i386.deb
Files:
47ce18d1fc371547a8fce39e61d392b5 1393 net extra rtorrent_0.8.7-4.dsc
3bca06106c0374e151700be2f824295b 10242 net extra rtorrent_0.8.7-4.debian.tar.gz
f61b251f93837fb3900c56aac6aaa129 430986 net extra rtorrent_0.8.7-4_i386.deb
iEYEARECAAYFAk1qemwACgkQCFqbMnwsrrgH8wCg6sicG9aW/pXAkPoCcLKyQ9G2
QBMAnjKqQMLi/xnUW34oF4gfAy2epfhO
=tmEl
-----END PGP SIGNATURE-----
reopen 490277 notfixed 490277 0.8.7-4 thanks I'm not sure if there is any support on rtorrent now, but it's only listening on 0.0.0.0:6881 so the support clearly isn't all there. Kurt
We believe that the bug you reported is fixed in the latest version of rtorrent, which is due to be installed in the Debian FTP archive: rtorrent_0.8.7-5.debian.tar.gz to main/r/rtorrent/rtorrent_0.8.7-5.debian.tar.gz rtorrent_0.8.7-5.dsc to main/r/rtorrent/rtorrent_0.8.7-5.dsc rtorrent_0.8.7-5_i386.deb to main/r/rtorrent/rtorrent_0.8.7-5_i386.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 490277@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Rogério Brito <rbrito@ime.usp.br> (supplier of updated rtorrent package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmaster@debian.org) Format: 1.8 Date: Wed, 09 Mar 2011 20:16:36 -0300 Source: rtorrent Binary: rtorrent Architecture: source i386 Version: 0.8.7-5 Distribution: unstable Urgency: low Maintainer: Jose Luis Rivas <ghostbar@debian.org> Changed-By: Rogério Brito <rbrito@ime.usp.br> Description: rtorrent - ncurses BitTorrent client based on LibTorrent from rakshasa Closes: 490277 605863 Changes: rtorrent (0.8.7-5) unstable; urgency=low . * Add patch to fix segfault with xmlrpc commands. Closes: #605863. * Add patch to enable IPv6. Closes: #490277. * Update series file. Checksums-Sha1: 32e5dc2ccbd95f226448635838463fdf87fc817c 1393 rtorrent_0.8.7-5.dsc 6668af123e3e982e2eba308d4e61ead3cd20b23b 16243 rtorrent_0.8.7-5.debian.tar.gz d4d068e86912cd5694ad85a2b3edaf6c595b4870 554344 rtorrent_0.8.7-5_i386.deb Checksums-Sha256: f354f28c0af2e756390a331a8d2d23edce701144c847eb98e964ccd6141a5ed8 1393 rtorrent_0.8.7-5.dsc 5d544db7404782597526baad1faf3980d3557e9dd6e4c24146f261e2120993f3 16243 rtorrent_0.8.7-5.debian.tar.gz 38c7583c9ad95629dc973d98520abd23b9efee1c67281025bd90ff1d606fd0b6 554344 rtorrent_0.8.7-5_i386.deb Files: 39c906b8bc7ea66e7fc6ab46c17d2a32 1393 net extra rtorrent_0.8.7-5.dsc 4e30e3681ee583af7c1a7dd9ba586aac 16243 net extra rtorrent_0.8.7-5.debian.tar.gz 36f41bb029f7973a72b8260a1f405068 554344 net extra rtorrent_0.8.7-5_i386.deb iEYEARECAAYFAk14DN4ACgkQCFqbMnwsrrgHjwCbBMjSdlzWtB/JlS/J0Cf2Qw0s 53kAoKHMUYduFxyjeWnblvCfTcZ+JXxi =buDd -----END PGP SIGNATURE-----
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
reopen 490277 quit Hi, Michael. 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,
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? 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. Please consider an request for adoption or orphaning the package if you feel you don't want to maintain it anymore. Kurt
Hi, Kurt. Thank you very much for your feedback. It is really appreciated. 2011/9/30 Kurt Roeckx <kurt@roeckx.be>: 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). 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. 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 Yes, that's the one. Yes, but we lack a fix and upstream is not really responsive: http://thread.gmane.org/gmane.linux.network/199373 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,
Hi, Kurt. Thank you very much for your feedback. It is really appreciated. 2011/9/30 Kurt Roeckx <kurt@roeckx.be>: 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). 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. 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 Yes, that's the one. Yes, but we lack a fix and upstream is not really responsive: http://thread.gmane.org/gmane.linux.network/199373 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,
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. Can you show me the patches and versions you're trying to build? 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 ;) 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. Especially as the package has 2 more maintainers. 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
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. Can you show me the patches and versions you're trying to build? 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 ;) 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. Especially as the package has 2 more maintainers. 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
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 */
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 */
Hi. Sorry for the late reply, but things are quite hectic here. 2011/9/30 Steinar H. Gunderson <sgunderson@bigfoot.com>: 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,
Hi. Sorry for the late reply, but things are quite hectic here. 2011/9/30 Steinar H. Gunderson <sgunderson@bigfoot.com>: 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,
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 */
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 */
We believe that the bug you reported is fixed in the latest version of
libtorrent, which is due to be installed in the Debian FTP archive:
libtorrent-dev_0.12.9-3_amd64.deb
to main/libt/libtorrent/libtorrent-dev_0.12.9-3_amd64.deb
libtorrent14_0.12.9-3_amd64.deb
to main/libt/libtorrent/libtorrent14_0.12.9-3_amd64.deb
libtorrent_0.12.9-3.debian.tar.gz
to main/libt/libtorrent/libtorrent_0.12.9-3.debian.tar.gz
libtorrent_0.12.9-3.dsc
to main/libt/libtorrent/libtorrent_0.12.9-3.dsc
libtorrent_0.12.9.orig.tar.gz
to main/libt/libtorrent/libtorrent_0.12.9.orig.tar.gz
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 490277@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Rogério Brito <rbrito@ime.usp.br> (supplier of updated libtorrent package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)
Format: 1.8
Date: Thu, 13 Oct 2011 13:54:16 -0300
Source: libtorrent
Binary: libtorrent-dev libtorrent14
Architecture: source amd64
Version: 0.12.9-3
Distribution: unstable
Urgency: medium
Maintainer: Jose Luis Rivas <ghostbar@debian.org>
Changed-By: Rogério Brito <rbrito@ime.usp.br>
Description:
libtorrent-dev - C++ BitTorrent library by Rakshasa (development files)
libtorrent14 - C++ BitTorrent library by Rakshasa
Closes: 490277 644031
Changes:
libtorrent (0.12.9-3) unstable; urgency=medium
.
* Urgency medium due to RC bugfix. Closes: #644031.
* debian/patches: Fix compilation with IPv6. Closes: #490277.
Thanks to Steinar H. Gunderson.
Checksums-Sha1:
53fd02156859dc44e2136e7ffe3b942e725b65c2 1466 libtorrent_0.12.9-3.dsc
176a836c6e685e4dad71ac08c0e09caaa5b7757c 667864 libtorrent_0.12.9.orig.tar.gz
c4cd076e9f6cce6e45dd95ddca16c149d79741c4 24724 libtorrent_0.12.9-3.debian.tar.gz
70974a8c7f3195d30fc011ae32ae47e89a84e771 57846 libtorrent-dev_0.12.9-3_amd64.deb
8697484fa21c84782969a92b871aea6ffe87129d 405286 libtorrent14_0.12.9-3_amd64.deb
Checksums-Sha256:
a6a3cb1789bf7fe47bf287b9557740f851ddd4f8fc4e46a989274a5f5dda5409 1466 libtorrent_0.12.9-3.dsc
15dc9e8dd45d070f447e599bef08ef0ca421bac6e7f55e608dcd19360594af64 667864 libtorrent_0.12.9.orig.tar.gz
3e6cf620076d8930d3a55099280dc1d6f568a905ab1d2f32b0e0b4bd88962a5a 24724 libtorrent_0.12.9-3.debian.tar.gz
331106ad5e361f63d2174d68568c3cc7e92602e663b9691de8cf76ba9c8f09a0 57846 libtorrent-dev_0.12.9-3_amd64.deb
a17b47f92daf8d478965a166547280167dbc379c49fe8c7b4e15c19dea0176ce 405286 libtorrent14_0.12.9-3_amd64.deb
Files:
0cc7da7ef0f741749c9dd3ed97627e3a 1466 libs extra libtorrent_0.12.9-3.dsc
b128bbd324f03eb42ef5060080f87548 667864 libs extra libtorrent_0.12.9.orig.tar.gz
dba9fcc7e88ea9e7eb271c46745ff975 24724 libs extra libtorrent_0.12.9-3.debian.tar.gz
0b03a4c724912167bc43ed0cd440535b 57846 libdevel extra libtorrent-dev_0.12.9-3_amd64.deb
298fbfe42212d5f38b0a64cc8a6535b8 405286 libs extra libtorrent14_0.12.9-3_amd64.deb
iEYEARECAAYFAk6cJUwACgkQNFDtUT/MKpCwFQCgh9+5gyq9vHPe4TTwmkEInV6Q
QcEAn1U0ExVSZhsvScXYPeA37X+FCAH9
=Ffyd
-----END PGP SIGNATURE-----
Bug does not resolved.
~# netstat -nap | grep tor
tcp 0 0 0.0.0.0:6883 0.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.
reassign 490277 rtorrent fixed 490277 0.8.7-5 found 490277 0.8.9-1 fixed 490277 0.8.9-2 found 490277 0.9.2-1 severity 490277 important thanks rtorrent 0.9.0-1 (unreleased) removed IPv6 support again by dropping the patch, claiming upstream was now supporting it. This is simply false, and I haven't been able to get a response from the rtorrent maintainers about it. Thus, I'm reopening this bug, and setting to important as per the release goals. /* Steinar */
Control: forwarded -1 https://github.com/rakshasa/rtorrent/issues/59 IPv6 has finally been merged upstream. I have asked the author to make a release ASAP if he wants to get it into Stretch. Bernhard
Dear Maintainer, Jessie will remain in support for some time still. Please add libtorrent and rtorrent package versions from stretch (rtorrent 0.9.6) to jessie-backports so that a full dist-upgrade is not necessary to use IPv6 in rtorrent. Thanks, Jon Lane
Hello Please confirm if this email address is active? I sent you a message earlier, did you get it? Kindly get back to me Best regards
Hello Please confirm if this email address is active? I sent you a message earlier, did you get it? Kindly get back to me Best regards
Hello Please confirm if this email address is active? I sent you a message earlier, did you get it? Kindly get back to me Best regards