0.15.4 has matured enough to use. Please respond ASAP as I don't wish to report you MIA.
email sent.
rb_libtorrent is not usable in F15 http://koji.fedoraproject.org/koji/taskinfo?taskID=2763669
(In reply to comment #3) > rb_libtorrent is not usable in F15 > http://koji.fedoraproject.org/koji/taskinfo?taskID=2763669 However rb_libtorrent 0.15.5 won't compile with current rawhide boost either http://koji.fedoraproject.org/koji/taskinfo?taskID=2765024
(In reply to comment #4) > (In reply to comment #3) > > rb_libtorrent is not usable in F15 > > http://koji.fedoraproject.org/koji/taskinfo?taskID=2763669 > > However rb_libtorrent 0.15.5 won't compile with current rawhide > boost either > http://koji.fedoraproject.org/koji/taskinfo?taskID=2765024 There seems to be a version struggle between boost filesystem v2 & v3 I tried this and got a little further. --- libtorrent-rasterbar-0.15.5.orig/include/libtorrent/debug.hpp 2009-08-26 07:19:55.000000000 +0100 +++ libtorrent-rasterbar-0.15.5/include/libtorrent/debug.hpp 2011-02-07 14:26:46.786639260 +0000 @@ -57,7 +57,7 @@ namespace libtorrent { // DEBUG API - namespace fs = boost::filesystem; + namespace fs = boost::filesystem3; struct logger { --- libtorrent-rasterbar-0.15.5.orig/include/libtorrent/file_storage.hpp 2010-04-10 22:48:34.000000000 +0100 +++ libtorrent-rasterbar-0.15.5/include/libtorrent/file_storage.hpp 2011-02-07 14:35:03.936508549 +0000 @@ -53,7 +53,7 @@ POSSIBILITY OF SUCH DAMAGE. namespace libtorrent { - namespace fs = boost::filesystem; + namespace fs = boost::filesystem3; struct TORRENT_EXPORT file_entry { http://koji.fedoraproject.org/koji/taskinfo?taskID=2767224 http://koji.fedoraproject.org/koji/getfile?taskID=2767225&name=build.log It looks like there is also a gcc 4.6.0 issue as well
Created attachment 477435 [details] My pathetic effort
Well, it seems that adding -DBOOST_FILESYSTEM_VERSION=2 is enough: http://koji.fedoraproject.org/koji/taskinfo?taskID=2768213 Leigh, would you check this? (I just built this and have not tried using this yet). Note that with the same workaround I also rebuilt rb_libtorrent-0.14.11-2.fc15 http://koji.fedoraproject.org/koji/taskinfo?taskID=2768191 so for now you can use this on rawhide buildtree.
(In reply to comment #7) > Well, it seems that adding -DBOOST_FILESYSTEM_VERSION=2 is > enough: > http://koji.fedoraproject.org/koji/taskinfo?taskID=2768213 > Leigh, would you check this? (I just built this and have not > tried using this yet). > > Note that with the same workaround I also rebuilt > rb_libtorrent-0.14.11-2.fc15 > http://koji.fedoraproject.org/koji/taskinfo?taskID=2768191 > so for now you can use this on rawhide buildtree. I'm having to patch qbittorrent and torium to use v2, is it possible to patch libtorrent-rasterbar.pc to include the -DBOOST_FILESYSTEM_VERSION=2 cflag to fix this issue
(In reply to comment #8) > I'm having to patch qbittorrent and torium to use v2, is it possible to patch > libtorrent-rasterbar.pc to include the -DBOOST_FILESYSTEM_VERSION=2 cflag to > fix this issue Good catch, thank you. Would you try 0.14.10: http://koji.fedoraproject.org/koji/buildinfo?buildID=220557 and 0.15.5: http://koji.fedoraproject.org/koji/taskinfo?taskID=2786413 ?
(In reply to comment #9) > > Would you try > 0.14.10: > http://koji.fedoraproject.org/koji/buildinfo?buildID=220557 > and 0.15.5: > http://koji.fedoraproject.org/koji/taskinfo?taskID=2786413 > ? Yes, it may be a while till the rawhide buildroot updates (it's been 5 hours+ without updating). I will try 0.15.5 when the fuss dies down.
(In reply to comment #9) > (In reply to comment #8) > > I'm having to patch qbittorrent and torium to use v2, is it possible to patch > > libtorrent-rasterbar.pc to include the -DBOOST_FILESYSTEM_VERSION=2 cflag to > > fix this issue > > Good catch, thank you. Would you try > 0.14.10: > http://koji.fedoraproject.org/koji/buildinfo?buildID=220557 > and 0.15.5: > http://koji.fedoraproject.org/koji/taskinfo?taskID=2786413 > ? I have tested both versions in F15 with qbittorrent and the package functions as expected. I have also tested 0.15.5 python bindings with Miro and it work great. Can you push 0.15.5 to F15? Thanks Leigh
(In reply to comment #11) > I have tested both versions in F15 with qbittorrent and the package functions > as expected. > I have also tested 0.15.5 python bindings with Miro and it work great. Thank you for testing. > Can you push 0.15.5 to F15? Well, I am not the maintainer of rb_libtorrent, however as we definitely should push 0.15.5 into F-15 and branching is to happen, I will push this.
Well, on my environ $ fedpkg new-sources aborts....
(In reply to comment #13) > Well, on my environ $ fedpkg new-sources aborts.... Try updating to the latest version (fedpkg-0.5.3.0)
(In reply to comment #14) > (In reply to comment #13) > > Well, on my environ $ fedpkg new-sources aborts.... > Try updating to the latest version (fedpkg-0.5.3.0) Well, actually it was due to my failure, %changelog date entry was not in order... rb_libtorrent 0.15.5-1 is now built. http://koji.fedoraproject.org/koji/buildinfo?buildID=227901 Now waiting for kojira's new-repo task for dist-f15-build.
Okay, now * rb_libtorrent-0.15.5-2.fc15 was built, soname changing * qbittorrent-2.7.0-0.2.beta1.fc15 torium-0.4.2-14.fc15 were rebuilt against new rb_libtorrent - Now new patch is needed for torium to include needed header files in boost, old rb_libtorrent was pulling in the header files needed for torium + deluge 1.3.1 is working well with rb_libtorrent 0.15.5 ! fatrat, springlobby also need rebuilding against new rb_libtorrent, however for now I have not requested rebuild yet because they fail to build with old rb_libtorrent, due to the change in boost.
(In reply to comment #16) > Okay, now > * rb_libtorrent-0.15.5-2.fc15 was built, soname changing > * qbittorrent-2.7.0-0.2.beta1.fc15 > torium-0.4.2-14.fc15 > were rebuilt against new rb_libtorrent > - Now new patch is needed for torium to include needed header files > in boost, old rb_libtorrent was pulling in the header files needed > for torium > + deluge 1.3.1 is working well with rb_libtorrent 0.15.5 > > ! fatrat, springlobby also need rebuilding against new rb_libtorrent, > however for now I have not requested rebuild yet because > they fail to build with old rb_libtorrent, due to the change in > boost. Thank you for patching torium for 0.15.x , I will forward the patch upstream.
(In reply to comment #16) > Okay, now > > ! fatrat, springlobby also need rebuilding against new rb_libtorrent, > however for now I have not requested rebuild yet because > they fail to build with old rb_libtorrent, due to the change in > boost. Here's my thank you I have patched the libnotify issue and specified boost_filesystem version and it builds OK here SRPM: http://leigh123linux.fedorapeople.org/pub/srpm/springlobby-0.120-3.fc15.src.rpm
I have added gilboad to this ticket as I'm getting spammed with his build failure for springlobby. The srpm in post #18 should fix the build issue.
Thanks for the head's up. I'll add this to the next springlobby build. - Gilboa
FWIW, -DBOOST_FILESYSTEM=2 should be considered a temporary workaround. Support for boost::filesystem v2 will go away eventually.
(In reply to comment #21) > FWIW, -DBOOST_FILESYSTEM=2 should be considered a temporary workaround. > Support for boost::filesystem v2 will go away eventually. But not on F-15, will it? F-15 branch is already split from rawhide and removing v2 boost::filesystem on F-15 will be considered unacceptable on F-15 at this time.
And if boost::filesystem v2 supports go away on F-16, you should announce it on devel list.
(In reply to comment #22) > (In reply to comment #21) > > FWIW, -DBOOST_FILESYSTEM=2 should be considered a temporary workaround. > > Support for boost::filesystem v2 will go away eventually. > > But not on F-15, will it? F-15 branch is already split from rawhide and > removing v2 boost::filesystem on F-15 will be considered unacceptable > on F-15 at this time. No, certainly not. Exactly when it will happen is a question. It says here: http://beta.boost.org/doc/libs/1_46_0_beta1/libs/filesystem/v3/doc/index.htm that it will be gone in .48. That will likely be the version in F16, given our schedules.
(In reply to comment #24) > (In reply to comment #22) > > (In reply to comment #21) > > > FWIW, -DBOOST_FILESYSTEM=2 should be considered a temporary workaround. > > > Support for boost::filesystem v2 will go away eventually. > > > > But not on F-15, will it? F-15 branch is already split from rawhide and > > removing v2 boost::filesystem on F-15 will be considered unacceptable > > on F-15 at this time. > > No, certainly not. Exactly when it will happen is a question. It says here: > http://beta.boost.org/doc/libs/1_46_0_beta1/libs/filesystem/v3/doc/index.htm > that it will be gone in .48. That will likely be the version in F16, given our > schedules. Okay, thank you for information.
Once closing.