Created attachment 156621 [details] patch libtorrent-rasterbar Recently released new version of qbittorrent. Notes: * Removed meaningless pkg-message
Created attachment 156622 [details] shar qbittorrent
Hold on on this, will add poudriere logs
Created attachment 156624 [details] shar qbittorrent
Created attachment 156625 [details] shar libtorrent-rasterbar
Created attachment 156627 [details] poudriere libtorrent-rasterbar
Created attachment 156628 [details] poudriere qbittorrent
Created attachment 156629 [details] shar qbittorrent
Created attachment 156631 [details] shar libtorrent-rasterbar
libtorrent-rasterbar has Plist issues, will commit an update
Created attachment 156632 [details] shar libtorrent-rasterbar All fixed.
Created attachment 156652 [details] shar qbittorrent
Created attachment 156733 [details] shar qbittorrent
@Yuri Changes to existing ports are required in diff format (produced via svn diff, duff -U or port diff). Can you please obsolete the existing attachments and attach new ones. Also, normally we expect each port change to be split into individual issues for various reasons (CC/Assign correct maintainers, among other things). It's not entirely clear in this issue if there is in fact a need to commit these together in a single commit. Please confirm whether or not this is the case and why. If this is not the case, can I please request that these two updates are split into individual issues, with one depending or blocking the other according to the order in which they need to be committed. If you would also like to take maintainership of these, feel free to modify the MAINTAINER line in each port. Thanks for your ongoing contributions to FreeBSD!
These two are closely related, qbittorrent is probably the only user. They need to be committed together, that's why I submitted them this way. Not sure if qbittorrent will even compile with the old version.
Created attachment 157003 [details] patch qbittorrent: shar->patch
Created attachment 157004 [details] patch libtorrent-rasterbar libtorrent-rasterbar: shar->patch
Comment on attachment 157003 [details] patch Port not maintained, implicitly approved
Comment on attachment 157004 [details] patch libtorrent-rasterbar Port not maintained, implicitly approved
Created attachment 157571 [details] Error log Hi, While testing in poudriere I'm getting a failure with qbittorrent. I'm attaching the error log of a build. If you look at the last compiler lines you'll see some mangled option in the command line which clang does not understand. I suspect the problem happens in configure line 5805, in the extract function. That substitution is running wild here. Can you please investigate this issue? Thanks.
Created attachment 157583 [details] patch libtorrent-rasterbar (fixed missing patch removal)
Created attachment 157584 [details] patch qbittorrent (configure bug patched) This is a bug in the upstream qbittorrent's configure script, that I actually noticed and reported to them back then, but forgot to include into the port patch because it was building for me for whatever reason. Updated the patch.
Created attachment 157586 [details] patch qbittorrent (configure bug patched)
My poudriere build passes, but command lines still look weird (have with -nI/u... arguments). Please hold until I resolve this issue with qbittorrent, because their patch for this still isn't working 100%.
Pending resolution of upstream https://github.com/qbittorrent/qBittorrent/issues/3169
Created attachment 157589 [details] patch qbittorrent (configure bug patched)
Now the problem should be gone.
Created attachment 157591 [details] patch qbittorrent Removed undue 'uTorrent replacement' description. qBittorrent is a good client in its own right.
(In reply to yuri from comment #27) I'm going to test these new patches shortly, but looking at them I noticed one thing which slipped by me with the previous set. Why are you removing the #include <openssl/rand.h> line from torrent.cpp? Is that really needed? It should work fine as is IMHO. Thanks.
I agree, patch-src_torrent.cpp is erroneous. Please remove it.
The old patches were adding more #include <openssl/rand.h>, I removed them. But accidentally also removed one such line from upstream too.
Created attachment 157642 [details] Revised patch (for both ports) Hi again, I tested the new patch, and made a few modifications to it. I'm attaching a revised unified patch for both ports, relative to the ports root. some explanations: - I sorted USES - Removed the STRIP option, leaving only DEBUG: stripping is the default. in bsd.ports.mk there's logic to make ${STRIP_CMD} a noop when the DEBUG option is on (it checks for WITH_DEBUG, which is automatically defined by bsd.options.mk when the DEBUG option is on) so there's no need for an explicit STRIP option. Also, in libtorrent-rasterbar, when STRIP was off there was a line stripping ${STAGEDIR}${PREFIX}/lib/${PYTHON_VERSION}/site-packages/libtorrent.so, which I found no tracce off, so I removed that part. Also, why strip any binary if stripping is disabled? Anyway it now relies on the DEBUG option. - in qbittorrent Added compiler:c++11-lang, and removed thee line CONFIGURE_ENV+= QMAKESPEC=freebsd-clang, this forces using clang on all OS versions, even if the user asks for another compiler or the sysstem does not have it. ports infrastructure already takes care of that also allowing the user to request another compiler (choosing between gcc and clang for example), and automatically caters for requirements of different OS versions and architecctures wwhenever possible(for example, clang isn't available on all supported architectures, never rely on that) I also moved the DBUS USE_QT4 to an option helper. Can you please review these changes and check I did not modify the port in any incompatible way? That means, that it works fine! I'll wait for your feedback. Thanks.
Why did you need to add compiler:c++11-lang when they both compile fine as-is? Eventually compiler:c++11-lang will be retired anyways, because this will be the default. I don't think there is the need to be proactive with this. I agree, STRIP option should be retired not only here, but on all ports. I didn't make these ports, only updated them to the latest versions when they came up. Patch looks good to me.
(In reply to yuri from comment #32) We agree on most things, I asked for your review since I think you use these ports and could test them running. Regarding USES compiler I think you are missing the whole point of the flag. The following explanation iss a little long, it's not an attack on you, I just write it for you because I think it can help you for future contributions. First in my testing the port was failing in 8.4, where there is no clang in base system, so we need to explicitly depend on it. 8.4 is to be supported till the end of the month. Also The world isn't limited to amd64 and i386, at present clang isn't working for powerpc and mips architectures, so the ports system needs logic to allow choosing an alternative compiler when needed, and USES compiler helps with this. The point of USES compiler is to allow ports to define which features they expect from the compiler being used and the ports system takes care of the details, also accounting for users preferences(f.e. FAVORITE_COMPILER). The system could also choose to use clang from ports instead of clang from base for whatever reason(newer version which solves a known bug exposed by some port using a certain feature for example). As an example there is compiler:openmp, which requires an openmp capable compiler. At present this calls for gcc, but once clang grows the needed feature the compiler.mk file can be updated and ports automatically get the updated dependency(an exp-run would be performed before such a change, obviously). Also, on 9.x the default behavior is to use gcc unless really required, so the flag will still be of use for the whole lifetime of 9.x. So the compiler:c++11-lang is going to stay for the foresseeable future, maybe 10 or 15 years from now it will be discontinued but I can't see it going away in the next three or four at least. It's definitely needed until 8.4 (just a few days) and 9.3 (one year and half) are to be supported. Finally it worked by hardcoding the string "clang" as compiler, which by chance works on 9.x, 10.x and head, but is something to be avoided at all costs. It used to be quite common before the transition to clang for ports to simply hardcode the string "gcc" and a major cause of headaches when clang and newer versions of gcc with different names (gcc48, for example) appeared. using compiler:something is usually the way to go unless you have tested the port to successfully build and work with all the supported releases base compiler, and is to be preferred to any other hacks if it's able to solve the problem. Hope my explanation clears the whole complicated matter. This was not a problem a few years ago when everything was able to build with gcc 4.2.x from base. Now with a miscellanea of versions of gcc and clang around things are definitely more difficult.
Committed, thanks for your submission!
A commit references this bug: Author: madpilot Date: Thu Jun 11 20:44:37 UTC 2015 New revision: 389250 URL: https://svnweb.freebsd.org/changeset/ports/389250 Log: - Update libtorrent-rasterbar to 1.0.4 - Update qbittorrent 3.2.0 - Use Github masterisite for qbittorrent - Remove STRIP option, it's the default, and can be inhibited with the DEBUG option - Pet some portlint warnings PR: 200108 Submitted by: yuri at rawbw.com Changes: head/net-p2p/libtorrent-rasterbar/Makefile head/net-p2p/libtorrent-rasterbar/distinfo head/net-p2p/libtorrent-rasterbar/files/patch-include-libtorrent-config.hpp head/net-p2p/libtorrent-rasterbar/files/patch-libressl head/net-p2p/libtorrent-rasterbar/files/patch-src_lazy__bdecode.cpp head/net-p2p/libtorrent-rasterbar/files/patch-src_utp__stream.cpp head/net-p2p/libtorrent-rasterbar/pkg-plist head/net-p2p/qbittorrent/Makefile head/net-p2p/qbittorrent/distinfo head/net-p2p/qbittorrent/files/patch-configure head/net-p2p/qbittorrent/pkg-descr head/net-p2p/qbittorrent/pkg-plist
Thanks!