1.3.3 (in-tree) and 1.3.5 (upstream current version) do not work correctly with rb_libtorrent-0.16.0 Some bugs found: http://dev.deluge-torrent.org/ticket/2083 http://forum.deluge-torrent.org/viewtopic.php?f=8&t=39665 https://bugs.archlinux.org/task/29414 Upstream recommends 0.15.x for the 1.3 branch
rb_libtorrent is not slotted, so setting < dependencies would not be legal, so this leaves us with package.masking (and possible lastriting) deluge
(In reply to comment #1) > rb_libtorrent is not slotted, so setting < dependencies would not be legal, > so this leaves us with package.masking (and possible lastriting) deluge The devmanual says nothing about < not being legal unless the package is slotted. http://devmanual.gentoo.org/general-concepts/dependencies/index.html I think a DEPEND="<net-libs/rb_libtorrent-0.16.0" would be legal and perfectly acceptable. At some pont, the only version below that that would need to be maintained would be 0.15.10 (or a later version if the 0.15 branch continues) and basically, if you want to use deluge (and not qbittorrent or any of the other consumers of rb_libtorrent), you're stuck with <0.16.0 (for now at least).
I am completely against lastritting this, I would wait a bit more to leave upstream time to update it
Was this even reported to upstream?
(In reply to comment #4) > Was this even reported to upstream? ignore this please :S
And I also think we should be able to use "<" depend (like a ton of packages are already doing in the tree)
(In reply to comment #6) > And I also think we should be able to use "<" depend (like a ton of packages > are already doing in the tree) Bug 311241, Comment #5 A package can't force downgrade on another package on a same stabilization level. Most definately not if it's headers and/or library, like rb_libtorrent is. What you are suggesting is fine is same as if I had "fixed" the libpng 1.5 bugs by just setting < dependencies and calling it a day... The options here are to: 1. package.mask new rb_libtorrent and wait for all reverse dependencies to become compatible 2. package.mask deluge waiting for compatible version 3. drop KEYWORDS to "" in every deluge ebuild (same as 2. but in a different way) 4. package.mask deluge for removal (which is why treecleaner@ is now in CC) Once 1, 2, 3 or 4 is done, then you can set the < depend since it won't be forcing a downgrade on the same stabilization level anymore
This is really packaging ABC, I'm actually quite disappointed something this obvious isn't clear to everyone. It's common sense!
Is this is official policy, we need to start doing the same for many more packages (I remember a lot of sci* packages were forcing "<" deps and looks like nobody cared of that)
(In reply to comment #9) > Is this is official policy, we need to start doing the same for many more > packages (I remember a lot of sci* packages were forcing "<" deps and looks > like nobody cared of that) Is -> If Also, starting to "try to clean packages" only 10 days after 0.16 release looks too fast to me (we don't even have that recommended 0.15.10 in stable yet) And, are the rest of packages in the tree depending on net-libs/rb_libtorrent still working ok with 0.16.0?
(In reply to comment #9) > Is this is official policy, we need to start doing the same for many more > packages (I remember a lot of sci* packages were forcing "<" deps and looks > like nobody cared of that) Of course it's an official policy to not break the tree integrity (which is what setting < dependencies on same stabilization level essentially is). It seems to me that the first failure here was the bump of rb_libtorrent-0.16.0 to ~arch instead of package.mask for testing. I try to catch many as these cases I can, but absolutely if some sci@ or others have slipped through, they should be addressed
OK, then will try to report this issues when I found them, maybe a tracker (assigned to QA and with a reasoning) would be better. Could you please open that tracker bug with explanation about the problem and options to handle it? (looks like slotting if possible, dropping keywords, masking for removal...) Regarding this exact issue, I would vote for hardmasking rb_libtorrent-0.16, looks like it has a few consumers in the tree and deluge looks like a important one to me, also, deluge has an active upstream and they are aware of the problem, and nothing is forcing us (yet) to move to 0.16 soon
Another option is using the included libtorrent...if that makes you more happy...
The patch mentioned in http://dev.deluge-torrent.org/ticket/2083 restores Magnet link handling. With this patch Deluge works just fine (for me) against 0.16.0.
IMHO, it sounds like the bug is in net-libs/rb_libtorrent, not in deluge. I reported the bug in libtorrent: https://code.google.com/p/libtorrent/issues/detail?id=317
From the libtorrent bug tracker: https://code.google.com/p/libtorrent/issues/detail?id=317#c1 "Thanks. This has already been fixed in the release branch and will be in 0.16.1" So it looks like the resolution to this issue should be that net-libs/rb_libtorrent is bumped to 0.16.1 (once 0.16.1 is released, of course), and nothing should be done to deluge.
Reassigning to rb_libtorrent maintainers then
There is nothing for us ( rb_littorrent maintainers ) to do here. There is no new release of rb_libtorrent so I see no reason for us to be here. This bug should be handled by net-p2p@ team and closed once the new rb_litorrent hits the tree
Cannot the patch be applied to our version?
Created attachment 311651 [details, diff] Fix for magnet links
Created attachment 311653 [details, diff] Fix for ebuild to include patch
(In reply to comment #19) > Cannot the patch be applied to our version? Sure it can, see attachments. Works for me just fine.
rb_libtorrent-0.16.1 is out and contains the upstream fix I attached previously, as well as several others. It works fine with deluge 1.3.5 and makes this bug obsolete.
0.16.1 is now in tree
