Bug 242797 - net-p2p/py-libtorrent-rasterbar doesn't install anything
Summary: net-p2p/py-libtorrent-rasterbar doesn't install anything
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: Yuri Victorovich
URL: https://github.com/arvidn/libtorrent/...
Keywords:
Depends on:
Blocks: 241202 242760
  Show dependency treegraph
 
Reported: 2019-12-22 09:41 UTC by Ruslan Makhmatkhanov
Modified: 2020-03-08 21:22 UTC (History)
7 users (show)

See Also:
bugzilla: maintainer-feedback? (yuri)
koobs: merge-quarterly?


Attachments
py-libtorrent-rasterbar-with-patch-from-GH-PR.patch (1.93 KB, patch)
2020-01-07 16:12 UTC, Yuri Victorovich
no flags Details | Diff
Use version 1.2.3 and the patch from se-m at https://github.com/arvidn/libtorrent/pull/4234 (3.16 KB, patch)
2020-01-11 20:47 UTC, Ivan
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ruslan Makhmatkhanov freebsd_committer freebsd_triage 2019-12-22 09:41:44 UTC
If I understand correctly, py-libtorrent-rasterbar is broken - it doesn't installs anything. Look like some plist problem. This is why deluge is not capable to find libtorrent module.

[rm@cf ~]> pkg list py37-libtorrent-rasterbar-1.2.2
/usr/local/lib/python3.7/site-packages/python_libtorrent-1.2.2-py3.7.egg-info/PKG-INFO
/usr/local/lib/python3.7/site-packages/python_libtorrent-1.2.2-py3.7.egg-info/SOURCES.txt
/usr/local/lib/python3.7/site-packages/python_libtorrent-1.2.2-py3.7.egg-info/dependency_links.txt
/usr/local/lib/python3.7/site-packages/python_libtorrent-1.2.2-py3.7.egg-info/top_level.txt
/usr/local/share/licenses/py37-libtorrent-rasterbar-1.2.2/BSD3CLAUSE
/usr/local/share/licenses/py37-libtorrent-rasterbar-1.2.2/LICENSE
/usr/local/share/licenses/py37-libtorrent-rasterbar-1.2.2/catalog.mk

It only installs a bunch of text files.
Comment 1 Yuri Victorovich freebsd_committer freebsd_triage 2019-12-22 10:40:58 UTC
I reported this regression upstream.
Comment 2 Ruslan Makhmatkhanov freebsd_committer freebsd_triage 2019-12-22 19:33:57 UTC
libtorrent-rasterbar in ports tree builds against python2.7 uncoditionally. I think that is culprit:

USES=           cmake compiler:c++14-lang iconv:wchar_t libtool pathfix pkgconfig python:2.7,test shebangfix ssl

this restriction was added in 1.1.10 -> 1.2.2 update.
Comment 3 Yuri Victorovich freebsd_committer freebsd_triage 2019-12-22 19:35:26 UTC
(In reply to Ruslan Makhmatkhanov from comment #2)

In the linked GitHub issue they are working on this.
Comment 4 commit-hook freebsd_committer freebsd_triage 2019-12-22 19:38:57 UTC
A commit references this bug:

Author: yuri
Date: Sun Dec 22 19:38:54 UTC 2019
New revision: 520654
URL: https://svnweb.freebsd.org/changeset/ports/520654

Log:
  net-p2p/py-libtorrent-rasterbar: Labeled as BROKEN, with the upstream working on resolving it

  PR:		242797

Changes:
  head/net-p2p/py-libtorrent-rasterbar/Makefile
Comment 5 Ruslan Makhmatkhanov freebsd_committer freebsd_triage 2019-12-22 19:44:15 UTC
(In reply to Yuri Victorovich from comment #3)

I saw the upstream report, but the problem is in our port it seems. Because the port itself introduces the python2.7 (why?) requirement when it was updated to 1.2.2. 

I mean reverting it to "USES= python", as if was before, may fix the things.
I'll try to test that.
Comment 6 Yuri Victorovich freebsd_committer freebsd_triage 2019-12-22 19:53:40 UTC
(In reply to Ruslan Makhmatkhanov from comment #5)

It seems to use python-3.7:
> $ make -V FLAVOR
> py37
> $ make -V PYTHON_CMD
> /usr/local/bin/python3.7
Comment 7 Ruslan Makhmatkhanov freebsd_committer freebsd_triage 2019-12-22 20:02:26 UTC
I talking about net-p2p/libtorrent-rasterbar:

[rm@cf svnports]> svn info | grep -i revis
Revision: 519577
[rm@cf svnports]> grep python net-p2p/libto
libtorrent-rasterbar/ libtorrent/           
[rm@cf svnports]> grep python net-p2p/libtorrent-rasterbar/Makefile 
USES=		cmake compiler:c++14-lang iconv:wchar_t libtool pathfix pkgconfig python:2.7,test shebangfix ssl
	@${REINPLACE_CMD} -e 's|python|${PYTHON_CMD}|' \
^^^^^^^^^^
Comment 8 Ruslan Makhmatkhanov freebsd_committer freebsd_triage 2019-12-23 05:45:45 UTC
Sadly, removing 2.7 limitation didn't helped. Ok, will wait upstream response, thanks.
Comment 9 Kubilay Kocak freebsd_committer freebsd_triage 2020-01-07 09:15:35 UTC
There appears to be a working (unverified) patch in https://github.com/arvidn/libtorrent/issues/4204#issuecomment-571066057 as of yesterday
Comment 10 Yuri Victorovich freebsd_committer freebsd_triage 2020-01-07 16:12:04 UTC
(In reply to Kubilay Kocak from comment #9)

It is an unmerged draft pull request. I am not sure it I should update the port with it.

I can't verify it. Instead, attaching the patch for soebody who uses python to verify.
Comment 11 Yuri Victorovich freebsd_committer freebsd_triage 2020-01-07 16:12:47 UTC
Created attachment 210505 [details]
py-libtorrent-rasterbar-with-patch-from-GH-PR.patch
Comment 12 Ruslan Makhmatkhanov freebsd_committer freebsd_triage 2020-01-07 18:19:47 UTC
(In reply to Kubilay Kocak from comment #9)

sadly, doesn't works here - still not building the extension.
Comment 13 Yuri Victorovich freebsd_committer freebsd_triage 2020-01-07 18:50:10 UTC
(In reply to Ruslan Makhmatkhanov from comment #12)

Please tell this to the upstream author in the GtHub issue.
Comment 14 Ruslan Makhmatkhanov freebsd_committer freebsd_triage 2020-01-07 21:26:46 UTC
(In reply to Yuri Victorovich from comment #11)
===>   py37-libtorrent-rasterbar-1.2.3.9 depends on file: /usr/local/sbin/pkg - found
=> arvidn-libtorrent-1_2_3-9-g96695fa71_GH0.tar.gz doesn't seem to exist in /portdistfiles/.
=> Attempting to fetch https://codeload.github.com/arvidn/libtorrent/tar.gz/1_2_3-9-g96695fa71?dummy=/arvidn-libtorrent-1_2_3-9-g96695fa71_GH0.tar.gz
fetch: https://codeload.github.com/arvidn/libtorrent/tar.gz/1_2_3-9-g96695fa71?dummy=/arvidn-libtorrent-1_2_3-9-g96695fa71_GH0.tar.gz: size unknown
fetch: https://codeload.github.com/arvidn/libtorrent/tar.gz/1_2_3-9-g96695fa71?dummy=/arvidn-libtorrent-1_2_3-9-g96695fa71_GH0.tar.gz: size of remote file is not known
arvidn-libtorrent-1_2_3-9-g96695fa71_GH0.tar.gz        3508 kB  683 kBps    05s
=> e71d2ca2d445db627308167cd551d4934af5f4af.patch is not in /usr/ports/net-p2p/py-libtorrent-rasterbar/distinfo.
=> Either /usr/ports/net-p2p/py-libtorrent-rasterbar/distinfo is out of date, or
=> e71d2ca2d445db627308167cd551d4934af5f4af.patch is spelled incorrectly.
*** Error code 1

Stop.
make: stopped in /usr/ports/net-p2p/py-libtorrent-rasterbar


Doesn't work here - manually applied this against 1.2.3 version. It complains there is no patch-file distinfo entry.
Comment 15 Ivan 2020-01-11 20:47:43 UTC
Created attachment 210636 [details]
Use version 1.2.3 and the patch from se-m at https://github.com/arvidn/libtorrent/pull/4234

The patch py-libtorrent-rasterbar-with-patch-from-GH-PR.patch did not work for me. 

I've ended up using the release 1.2.3 and making the port to apply the patch from se-m. Now it builds fine both py27 and py37 flavors.
Comment 16 Marc 2020-01-16 15:13:52 UTC
The fix is not complete because « Libtorrent 1.2.x isn't supported on deluge 1.x, only deluge 2.x, » like is said on the deluge forum https://forum.deluge-torrent.org/viewtopic.php?t=55535

Starting deluged service result in error message « AttributeError: 'module' object has no attribute 'session_settings' »
Comment 17 Walter Schwarzenfeld freebsd_triage 2020-02-01 16:09:51 UTC
Marked broken in ports r524769.
Comment 18 avatar4d 2020-02-20 21:38:45 UTC
Can't we revert libtorrent-rasterbar/py-libtorrent-rasterbar to the last working version so deluge can build again while we wait for the upstream fix rather than leave things broken? As it stands, pkg upgrade will remove deluge from a working system with the default /etc/pkg/FreeBSD.conf. If that happens they have to revert pkg config to release_1 to reinstall where they remain stuck in upgrade purgatory without playing some pkg lock games.
Comment 19 Yuri Victorovich freebsd_committer freebsd_triage 2020-02-20 21:55:24 UTC
(In reply to avatar4d from comment #18)

Please attach a patch that would do this that would build in poudriere.


Yuri
Comment 20 avatar4d 2020-02-21 03:26:04 UTC
(In reply to Yuri Victorovich from comment #19)

Ah, I see you are already doing that with your forks... at least it looks right to me. It's not building?
Comment 21 Yuri Victorovich freebsd_committer freebsd_triage 2020-02-21 03:38:10 UTC
(In reply to avatar4d from comment #20)

Users couldn't validate Deluge with it. You are welcome to try.

I personally don't use Deluge, so somebody should come up with a patch that can make it work if they can.
Comment 22 edgeman 2020-02-21 03:41:29 UTC
(In reply to avatar4d from comment #20)

I'm one of the users Yuri is referring to.

After ensuring deluge was installing py-libtorrent-rasterbar11 (the 1.1 fork Yuri added) I was receiving this on deluged start:

[ERROR   ] 08:58:58 main:248 No module named libtorrent
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/site-packages/deluge/main.py", line 241, in start_daemon
    Daemon(options, args)
  File "/usr/local/lib/python2.7/site-packages/deluge/core/daemon.py", line 144, in __init__
    from deluge.core.core import Core
  File "/usr/local/lib/python2.7/site-packages/deluge/core/core.py", line 38, 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: No module named libtorrent
Comment 23 Yuri Victorovich freebsd_committer freebsd_triage 2020-02-21 04:14:20 UTC
(In reply to edgeman from comment #22)

This is because py-libtorrent-rasterbar was broken at this revision too. It doesn't install anything. Either older revisions need to be digged up, or the issue needs to be fixed in py-libtorrent-rasterbar itself. Its author seems to not be able to fix it for some reason. Somebody with expertise in Python might be able to help.

It would be best if the upstream is fixed. Failure to install files might be a mundane problem or a complex problem, somebody needs to help there.
Comment 24 Yuri Victorovich freebsd_committer freebsd_triage 2020-03-08 21:22:04 UTC
Fixed by the commit r528047 for bug#244672