Bug 242797
| Summary: | net-p2p/py-libtorrent-rasterbar doesn't install anything | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Ruslan Makhmatkhanov <rm> | ||||||
| Component: | Individual Port(s) | Assignee: | Yuri Victorovich <yuri> | ||||||
| Status: | Closed FIXED | ||||||||
| Severity: | Affects Many People | CC: | avatar4d, edgeman, jordy, marc.pearson, renchap, rm, w.schwarzenfeld | ||||||
| Priority: | --- | Flags: | bugzilla:
maintainer-feedback?
(yuri) koobs: merge-quarterly? |
||||||
| Version: | Latest | ||||||||
| Hardware: | Any | ||||||||
| OS: | Any | ||||||||
| URL: | https://github.com/arvidn/libtorrent/issues/4204 | ||||||||
| See Also: | https://github.com/arvidn/libtorrent/issues/4204 | ||||||||
| Bug Depends on: | |||||||||
| Bug Blocks: | 241202, 242760 | ||||||||
| Attachments: |
|
||||||||
|
Description
Ruslan Makhmatkhanov
2019-12-22 09:41:44 UTC
I reported this regression upstream. 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. (In reply to Ruslan Makhmatkhanov from comment #2) In the linked GitHub issue they are working on this. 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 (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. (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 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}|' \
^^^^^^^^^^
Sadly, removing 2.7 limitation didn't helped. Ok, will wait upstream response, thanks. There appears to be a working (unverified) patch in https://github.com/arvidn/libtorrent/issues/4204#issuecomment-571066057 as of yesterday (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. Created attachment 210505 [details]
py-libtorrent-rasterbar-with-patch-from-GH-PR.patch
(In reply to Kubilay Kocak from comment #9) sadly, doesn't works here - still not building the extension. (In reply to Ruslan Makhmatkhanov from comment #12) Please tell this to the upstream author in the GtHub issue. (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. 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. 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' » Marked broken in ports r524769. 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. (In reply to avatar4d from comment #18) Please attach a patch that would do this that would build in poudriere. Yuri (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? (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. (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 (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. Fixed by the commit r528047 for bug#244672 |