Bug 212235 - net-p2p/libtorrent-rasterbar: update to 1.1.1
Summary: net-p2p/libtorrent-rasterbar: update to 1.1.1
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Kurt Jaeger
URL:
Keywords:
Depends on:
Blocks: 209132 213740
  Show dependency treegraph
 
Reported: 2016-08-29 11:04 UTC by Matthew Rezny
Modified: 2016-10-28 09:00 UTC (History)
7 users (show)

See Also:


Attachments
update net-p2p/libtorrent-rasterbar to 1.1.1 (19.67 KB, patch)
2016-08-29 11:04 UTC, Matthew Rezny
rezny: maintainer-approval+
Details | Diff
Remove redundant SHA1 implementation from the installed library (3.34 KB, patch)
2016-10-02 15:09 UTC, Mikhail Teterin
no flags Details | Diff
testing (721 bytes, patch)
2016-10-25 19:48 UTC, Kurt Jaeger
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Matthew Rezny freebsd_committer 2016-08-29 11:04:50 UTC
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
Comment 1 Pawel Pekala freebsd_committer 2016-08-31 11:21:29 UTC
ENOTIME right now
Comment 2 Kurt Jaeger freebsd_committer 2016-09-08 18:19:22 UTC
testbuilds@work
Comment 3 Kurt Jaeger freebsd_committer 2016-09-08 19:16:30 UTC
testbuilds are fine.
Comment 4 Mikhail Teterin freebsd_committer 2016-10-02 15:09:42 UTC
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
Comment 5 Matthew Rezny freebsd_committer 2016-10-02 22:04:12 UTC
(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?
Comment 6 Yuri Victorovich freebsd_committer 2016-10-18 09:25:32 UTC
Bug#209132 contains the recent patch. Patches there should be committed, this bugs should be closed.
Comment 7 Matthew Rezny freebsd_committer 2016-10-19 04:17:27 UTC
(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.
Comment 8 Yuri Victorovich freebsd_committer 2016-10-19 04:36:14 UTC
Okay, this should be committed first.
Comment 9 commit-hook freebsd_committer 2016-10-19 05:23:50 UTC
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
Comment 10 Kurt Jaeger freebsd_committer 2016-10-19 05:24:54 UTC
Committed, thanks for all the explainations around the diverse PRs on that issue.
Comment 11 edgeman 2016-10-22 05:57:30 UTC
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"
Comment 12 Kurt Jaeger freebsd_committer 2016-10-22 09:49:44 UTC
(In reply to edgeman from comment #11)
libtorrent.so is part of net-p2p/libtorrent ?

Did you rebuild net-p2p/libtorrent ?
Comment 13 Kurt Jaeger freebsd_committer 2016-10-22 10:06:15 UTC
I have reproduced the problem with a fresh build of deluge in poudriere on 11a.
Comment 14 edgeman 2016-10-22 15:09:43 UTC
(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!")
Comment 15 Thomas Zander freebsd_committer 2016-10-24 10:12:05 UTC
(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.
Comment 16 James French 2016-10-25 11:09:55 UTC
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.
Comment 17 Mikhail Teterin freebsd_committer 2016-10-25 13:29:51 UTC
> 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.
Comment 18 Kurt Jaeger freebsd_committer 2016-10-25 19:48:07 UTC
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...)
Comment 19 Kurt Jaeger freebsd_committer 2016-10-25 20:05:30 UTC
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"
Comment 20 Ruslan Makhmatkhanov freebsd_committer 2016-10-25 22:56:40 UTC
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.
Comment 21 edgeman 2016-10-26 00:37:37 UTC
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.
Comment 22 Ruslan Makhmatkhanov freebsd_committer 2016-10-26 06:45:39 UTC
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
Comment 23 Matthew Rezny freebsd_committer 2016-10-26 22:47:10 UTC
(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?
Comment 24 Ruslan Makhmatkhanov freebsd_committer 2016-10-28 08:54:08 UTC
(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?
Comment 25 Kurt Jaeger freebsd_committer 2016-10-28 09:00:46 UTC
Thanks to rm@ for fixing the fallout.