According to the official INSTALL docs¹, qBittorrent either depends on libtorrent-rasterbar 1.2 or 2.0. The RDEPEND in the current ebuild of qbittorrent-4.5.4 doesn’t reflect that though, it depends on <net-libs/libtorrent-rasterbar-2:= I suggest the following change to RDEPEND, which I tested and works for me: || ( >=net-libs/libtorrent-rasterbar-1.2.19:0/10 >=net-libs/libtorrent-rasterbar-2.0.9:0/2.0 ) The problem with this is that v1.2.19 of libtorrent-rasterbar is currently not available in Portage, and v2.0.9 would need to be stabilized. ¹ https://github.com/qbittorrent/qBittorrent/blob/master/INSTALL Reproducible: Always Steps to Reproduce: 1. emerge net-p2p/qbittorrent Actual Results: In Portage’s current state, qBittorrent is only built with net-libs/libtorrent-rasterbar-1.2.18-r1. Expected Results: qBittorrent should be buildable with the officially supported libtorrent-rasterbar versions.
This is intentional. The guard for libtorrent-2 has been added there due to libtorrent-2 triggering a bug in kernel that hangs the qbittorrent if you use XFS filesystem. Once there will be upstream fix in kernel I will remove this limitation and add ewarn about it, however up until either this is not fixed in mainline kernel or there are no any end-user facing issues because of using 1.2 series instead of 2.x I will keep this there. For more information you can check https://github.com/arvidn/libtorrent/issues/6952#issuecomment-1506674176 as well as https://bugs.gentoo.org/868480 > The problem with this is that v1.2.19 of libtorrent-rasterbar is currently not available in Portage, and v2.0.9 would need to be stabilized. This however is something I did not understand, while we do not have the 1.2.19 (that I will add in a moment), we have 1.2.18 that works with it just fine. I will be closing it as CANTFIX for now, but feel free to continue the discussion if you can elaborate on the problems you see with sticking to 1.2.x line of libtorrent.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=df57b2c77c540783f3a61563f96e7ec9a65328ca commit df57b2c77c540783f3a61563f96e7ec9a65328ca Author: Piotr Karbowski <slashbeast@gentoo.org> AuthorDate: 2023-06-23 09:49:57 +0000 Commit: Piotr Karbowski <slashbeast@gentoo.org> CommitDate: 2023-06-23 09:49:57 +0000 net-libs/libtorrent-rasterbar: 1.2.19 version bump. Bug: https://bugs.gentoo.org/908999 Signed-off-by: Piotr Karbowski <slashbeast@gentoo.org> net-libs/libtorrent-rasterbar/Manifest | 1 + .../libtorrent-rasterbar-1.2.19.ebuild | 70 ++++++++++++++++++++++ 2 files changed, 71 insertions(+)
Oh, I didn’t know that, and I haven’t searched for resolved/fixed bugs, otherwise I would have seen 868480. Is there any bug open (kept open) to track the eventual fix of the XFS problem in the kernel, so that we don’t forget about stabilizing 2.x? > This however is something I did not understand, while we do not have the > 1.2.19 (that I will add in a moment), we have 1.2.18 that works with it just > fine. I’m sorry, I didn’t look properly. • qBittorrent up to 4.5.4 are happy with 1.2.18+ or 2.0.8+. • qBittorrent 4.6.0alpha1 and higher (or the master branch) need 1.2.19+/2.0.9+.
(In reply to matthias.grobarek from comment #3) > Oh, I didn’t know that, and I haven’t searched for resolved/fixed bugs, > otherwise I would have seen 868480. > Is there any bug open (kept open) to track the eventual fix of the XFS > problem in the kernel, so that we don’t forget about stabilizing 2.x? I did not though about it but this is good idea to have tracking bug for it, I just opened one at https://bugs.gentoo.org/909511 I keep track of it as I use XFS and I was personally affected by this bug, the libtorrent 2.x is actually stabilized already, just qbittorrent does not pulls it in. The moment the real fix will hit kernel I will most likely prepare news item to make sure users of qbittorrent are aware that they'd need to get latest kernel first or their systems will deadlock heavily, there's a workaround patch but I do not think it should make its way into gentoo-sources in the way it is right now so I wait for the proper fix upstream.
