Created attachment 174180 [details] update net-p2p/libtorrent-rasterbar to 1.1.1 Update of net-p2p/libtorrent-rasterbar to 1.1.1 * remove 2 patches that are included in this release * rename the remaining patch to fit current convention * compile in C++11 mode as is required by qBittorrent versions after 3.3.4 * add 2 patches needed to compile in C++11 mode, one of which was extracted from the upstream git repo QA: poudriere testport (11/10/9 amd64/i386) portlint gives no FATALs and no new WARNs
ENOTIME right now
testbuilds@work
testbuilds are fine.
Created attachment 175366 [details] Remove redundant SHA1 implementation from the installed library This additional patch removes the SHA1-implementation from the library. It is not needed anywhere OpenSSL is used. Discussed with the upstream here: https://github.com/arvidn/libtorrent/issues/659
(In reply to Mikhail Teterin from comment #4) The patch that was attached is significantly different than the commit to the 1.1 branch linked in that issue. More importantly, what is the need to patch this prior to the next release considering it is unused code?
Bug#209132 contains the recent patch. Patches there should be committed, this bugs should be closed.
(In reply to yuri from comment #6) These ports should be updated in separate PRs, not one as Mikhail had tried to do before. This PR should NOT be closed without action. PR 209132 should have only ever been about updating qBittorrent, not libtorrent-rasterbar.
Okay, this should be committed first.
A commit references this bug: Author: pi Date: Wed Oct 19 05:23:21 UTC 2016 New revision: 424227 URL: https://svnweb.freebsd.org/changeset/ports/424227 Log: net-p2p/libtorrent-rasterbar: update 1.1.0 -> 1.1.1 - compile in C++11 mode as is required by qBittorrent versions after 3.3.4 PR: 212235 Submitted by: matthew@reztek.cz (maintainer) Changes: head/net-p2p/libtorrent-rasterbar/Makefile head/net-p2p/libtorrent-rasterbar/distinfo head/net-p2p/libtorrent-rasterbar/files/patch-git_3624ce6c head/net-p2p/libtorrent-rasterbar/files/patch-git_95e348be head/net-p2p/libtorrent-rasterbar/files/patch-include-libtorrent-config.hpp head/net-p2p/libtorrent-rasterbar/files/patch-include_libtorrent_config.hpp head/net-p2p/libtorrent-rasterbar/files/patch-include_libtorrent_tommath.h head/net-p2p/libtorrent-rasterbar/files/patch-src_kademlia_dht__tracker.cpp head/net-p2p/libtorrent-rasterbar/pkg-plist
Committed, thanks for all the explainations around the diverse PRs on that issue.
After this update I can no longer run net-p2p/deluge. The package does build, however I see the following in /var/tmp/deluge.log: [INFO ] 20:27:27 configmanager:70 Setting config directory to: /home/username/.config/deluge [INFO ] 20:27:27 daemon:124 Deluge daemon 1.3.13 [INFO ] 20:27:27 configmanager:70 Setting config directory to: /home/username/.config/deluge [ERROR ] 20:27:27 main:245 /usr/local/lib/python2.7/site-packages/libtorrent.so: Undefined symbol "_ZNK10libtorrent14announce_entry12can_announceEN5boost6chrono10time_pointINS2_12steady_clockENS2_8durationIlNS1_5ratioILl1ELl1000000000EEEEEEEb" Traceback (most recent call last): File "/usr/local/lib/python2.7/site-packages/deluge/main.py", line 238, in start_daemon Daemon(options, args) File "/usr/local/lib/python2.7/site-packages/deluge/core/daemon.py", line 141, in __init__ from deluge.core.core import Core File "/usr/local/lib/python2.7/site-packages/deluge/core/core.py", line 36, in <module> from deluge._libtorrent import lt File "/usr/local/lib/python2.7/site-packages/deluge/_libtorrent.py", line 59, in <module> import libtorrent as lt ImportError: /usr/local/lib/python2.7/site-packages/libtorrent.so: Undefined symbol "_ZNK10libtorrent14announce_entry12can_announceEN5boost6chrono10time_pointINS2_12steady_clockENS2_8durationIlNS1_5ratioILl1ELl1000000000EEEEEEEb" Additionally this can be reproduced with the following: $ python -c "import libtorrent; print libtorrent.version" Traceback (most recent call last): File "<string>", line 1, in <module> ImportError: /usr/local/lib/python2.7/site-packages/libtorrent.so: Undefined symbol "_ZNK10libtorrent14announce_entry12can_announceEN5boost6chrono10time_pointINS2_12steady_clockENS2_8durationIlNS1_5ratioILl1ELl1000000000EEEEEEEb"
(In reply to edgeman from comment #11) libtorrent.so is part of net-p2p/libtorrent ? Did you rebuild net-p2p/libtorrent ?
I have reproduced the problem with a fresh build of deluge in poudriere on 11a.
(In reply to Kurt Jaeger from comment #12) I don't have net-p2p/libtorrent installed. (My understanding is that is a different library entirely, in the libtorrent-rasterbar pkg-descr is this line "NB: this is NOT the same library as the net-p2p/libtorrent port!")
(In reply to Kurt Jaeger from comment #13) The exact same error can be observed with net-p2p/tribler, also on a fresh build in a clean environment (poudriere) on stable/11 amd64.
I spent a bit of time looking at this at the weekend, it seems to be related to the addition of c++11 mode and the python bindings getting built with the wrong set of flags. The issue isn't so much with net-p2p/libtorrent-rasterbar but rather net-p2p/libtorrent-rasterbar-python which is a slave port. Unfortunately I spent a couple of hours on it and it wasn't able to get any closer to a fix, have rolled my box back to 1.1.0 for the time being.
> seems to be related to the addition of c++11 mode Yes. The patch I created -- bundled for the Bug #209132 -- was built without the c++11 mode, using -DBOOST_ASIO_HAS_STD_CHRONO instead to solve the one symbol missing by qtorrent without it. I tested the resulting libtorrent-rasterbar against deluge back then, and it worked. Now that the library is built in c++11 mode instead, the consuming code of all the library-clients needs to be built with the same flag too.
Created attachment 176156 [details] testing Test-building deluge with this patched libtorrent-rasterbar. Thanks to mi for the idea (I have no idea if this is sufficient...)
It's not: [ERROR ] 22:03:28 main:245 /usr/local/lib/libtorrent-rasterbar.so.9: Undefined symbol "_ZN5boost4asio10io_service7serviceD2Ev" Traceback (most recent call last): File "/usr/local/lib/python2.7/site-packages/deluge/main.py", line 238, in start_daemon Daemon(options, args) File "/usr/local/lib/python2.7/site-packages/deluge/core/daemon.py", line 141, in __init__ from deluge.core.core import Core File "/usr/local/lib/python2.7/site-packages/deluge/core/core.py", line 36, in <module> from deluge._libtorrent import lt File "/usr/local/lib/python2.7/site-packages/deluge/_libtorrent.py", line 59, in <module> import libtorrent as lt ImportError: /usr/local/lib/libtorrent-rasterbar.so.9: Undefined symbol "_ZN5boost4asio10io_service7serviceD2Ev"
Oops, sorry as an always I'm discovering something after already doing something. I committed the fix for libtorrent-rasterbar-python in r424659 to make deluge work again.
An additional note, I've been told in the deluge IRC channel that deluge doesn't yet support libtorrent higher than 1.0.9 and that support for 1.1.x is being worked on for deluge v2.
I read that 1.1.0 had some issues with deluge 1.3.x, but I never faced any of them in my day-to-day usage (simple downloading with torrent file or magnet link). In version 1.1.1 they returned some compatibility shims for deluge, so it's actually safe to use deluge 1.3 with this version of libtorrent-rasterbar. I see no issues with the versions in the current ports tree. http://forum.deluge-torrent.org/viewtopic.php?f=7&t=53939&start=10
(In reply to Ruslan Makhmatkhanov from comment #20) No need to apologize. After the first email about the failure with Deluge it was immediately obvious that the python bindings were not being built in C++11 mode like the main library, but I did not have time until today to track down why that was, and now I see it's already been resolved, so thank you for committing that fix. Regarding the support for differing versions, as 1.1.0 was released after 1.0.9 and prior to 1.0.10, I did not realize that there was going to be a split. If need be, I can make a separate pair of ports for the 1.0.x version, but I do not think that will be necessary because Deluge did appear to work ok with 1.1.1 when I tested it before flipping the C++11 switch for the sake of qBittorrent. Sorry to the Deluge users for forgetting to recheck after that change. I was focused on getting qBittorrent updated and ensuring it worked everywhere (needed a patch for missing TLS support on 10) as that's the client I use. I'm no ports expert, but shouldn't it have been sufficient to bump PORTREVISION on just the slave?
(In reply to matthew from comment #23) Regarding PORTREVISION question: yes, I believe it was enough to just bump the revision at slave's Makefile. I was in hurry, sorry. Can we close this PR?
Thanks to rm@ for fixing the fallout.