Created attachment 507970 [details] emerge --info I cannot get net-p2p/qbittorrent-4.0.1 to build on my server. I currently have net-p2p/qbittorrent-3.3.7 installed (haven't been able to build any version since that version on this machine). When I attempt to upgrade to qbittorrent 4.0.1, it seems like portage is forcing the qt5 use flag off (not sure if this is the source of the issue or not). This may be related to https://bugs.gentoo.org/613194 which was supposed to have been fixed upstream in this release, but I don't how to verify that. Here's what I get when I try to build with portage: # emerge -1av qbittorrent These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ~] net-p2p/qbittorrent-4.0.1::gentoo [3.3.7::gentoo] USE="webui -X -dbus -debug (-qt5%*)" 0 KiB Total: 1 package (1 upgrade), Size of downloads: 0 KiB Would you like to merge these packages? [Yes/No] >>> Verifying ebuild manifests >>> Emerging (1 of 1) net-p2p/qbittorrent-4.0.1::gentoo * qbittorrent-4.0.1.tar.xz BLAKE2B SHA512 size ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking qbittorrent-4.0.1.tar.xz to /var/tmp/portage/net-p2p/qbittorrent-4.0.1/work >>> Source unpacked in /var/tmp/portage/net-p2p/qbittorrent-4.0.1/work >>> Preparing source in /var/tmp/portage/net-p2p/qbittorrent-4.0.1/work/qbittorrent-4.0.1 ... * Applying qbittorrent-4.0.1-nowebui.patch ... [ ok ] >>> Source prepared. >>> Configuring source in /var/tmp/portage/net-p2p/qbittorrent-4.0.1/work/qbittorrent-4.0.1 ... >>> Working in BUILD_DIR: "/var/tmp/portage/net-p2p/qbittorrent-4.0.1/work/qbittorrent-4.0.1_build" cmake -C /var/tmp/portage/net-p2p/qbittorrent-4.0.1/work/qbittorrent-4.0.1_build/gentoo_common_config.cmake -G Unix Makefiles -DCMAKE_INSTALL_PREFIX=/usr -DSYSTEM_QTSINGLEAPPLICATION=ON -DDBUS=no -DGUI=no -DWEBUI=yes -DCMAKE_BUILD_TYPE=Gentoo -DCMAKE_USER_MAKE_RULES_OVERRIDE=/var/tmp/portage/net-p2p/qbittorrent-4.0.1/work/qbittorrent-4.0.1_build/gentoo_rules.cmake -DCMAKE_TOOLCHAIN_FILE=/var/tmp/portage/net-p2p/qbittorrent-4.0.1/work/qbittorrent-4.0.1_build/gentoo_toolchain.cmake /var/tmp/portage/net-p2p/qbittorrent-4.0.1/work/qbittorrent-4.0.1 loading initial cache file /var/tmp/portage/net-p2p/qbittorrent-4.0.1/work/qbittorrent-4.0.1_build/gentoo_common_config.cmake -- The C compiler identification is GNU 6.4.0 -- The CXX compiler identification is GNU 6.4.0 -- Check for working C compiler: /usr/lib64/ccache/bin/x86_64-pc-linux-gnu-gcc -- Check for working C compiler: /usr/lib64/ccache/bin/x86_64-pc-linux-gnu-gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /usr/lib64/ccache/bin/x86_64-pc-linux-gnu-g++ -- Check for working CXX compiler: /usr/lib64/ccache/bin/x86_64-pc-linux-gnu-g++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Performing Test _PEDANTIC_IS_SUPPORTED -- Performing Test _PEDANTIC_IS_SUPPORTED - Success -- Detecting Glibc version... -- Glibc version is 225, adding -D_DEFAULT_SOURCE -- Performing Test _DEBUG_OPTIMIZATION_LEVEL_IS_SUPPORTED -- Performing Test _DEBUG_OPTIMIZATION_LEVEL_IS_SUPPORTED - Success -- Looking for pthread.h -- Looking for pthread.h - found -- Looking for pthread_create -- Looking for pthread_create - not found -- Looking for pthread_create in pthreads -- Looking for pthread_create in pthreads - not found -- Looking for pthread_create in pthread -- Looking for pthread_create in pthread - found -- Found Threads: TRUE -- libtorrent definitions: -DTORRENT_DISABLE_LOGGING;-DTORRENT_USE_OPENSSL;-DBOOST_ASIO_HASH_MAP_BUCKETS=1021;-DBOOST_EXCEPTION_DISABLE;-DBOOST_ASIO_ENABLE_CANCELIO;-DTORRENT_LINKING_SHARED;-I/usr/include/libtorrent -- Libtorrent Boost dependencies: system -- Boost version: 1.63.0 -- Found the following Boost libraries: -- system -- Found OpenSSL: /usr/lib64/libcrypto.so (found version "1.0.2m") -- Found LibtorrentRasterbar: /usr/lib64/libtorrent-rasterbar.so -- Project is built in RELEASE mode. -- Disabling debug output. -- Looking for Qt5 single application library CMake Error at cmake/Modules/FindQtSingleApplication.cmake:77 (MESSAGE): Could not find QtSingleApplication library Call Stack (most recent call first): src/CMakeLists.txt:85 (find_package) -- Configuring incomplete, errors occurred! See also "/var/tmp/portage/net-p2p/qbittorrent-4.0.1/work/qbittorrent-4.0.1_build/CMakeFiles/CMakeOutput.log". See also "/var/tmp/portage/net-p2p/qbittorrent-4.0.1/work/qbittorrent-4.0.1_build/CMakeFiles/CMakeError.log". * ERROR: net-p2p/qbittorrent-4.0.1::gentoo failed (configure phase): * cmake failed * * Call stack: * ebuild.sh, line 124: Called src_configure * environment, line 3337: Called cmake-utils_src_configure * environment, line 900: Called die * The specific snippet of code: * "${CMAKE_BINARY}" "${cmakeargs[@]}" "${CMAKE_USE_DIR}" || die "cmake failed"; * * If you need support, post the output of `emerge --info '=net-p2p/qbittorrent-4.0.1::gentoo'`, * the complete build log and the output of `emerge -pqv '=net-p2p/qbittorrent-4.0.1::gentoo'`. * The complete build log is located at '/var/tmp/portage/net-p2p/qbittorrent-4.0.1/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/net-p2p/qbittorrent-4.0.1/temp/environment'. * Working directory: '/var/tmp/portage/net-p2p/qbittorrent-4.0.1/work/qbittorrent-4.0.1_build' * S: '/var/tmp/portage/net-p2p/qbittorrent-4.0.1/work/qbittorrent-4.0.1' >>> Failed to emerge net-p2p/qbittorrent-4.0.1, Log file: >>> '/var/tmp/portage/net-p2p/qbittorrent-4.0.1/temp/build.log' emerge.info (emerge --info) and build.log are attached. Let me know if any other information would be useful
Created attachment 507972 [details] build.log
Created attachment 507974 [details] build.log
Created attachment 508002 [details] ebuild that works for me This is same bug as that suppose to be fixed in upstream but it wasnt. https://bugs.gentoo.org/613194 Anyway attached modified old ebuild that works for me.
I can confirm that this is still happening on 4.0.3. I can provide any logs on my end if necessary.
Please attach unified diffs rather than full ebuilds.
Does everyone else have ccache enabled too?
The issue has been fixed with this commit: https://github.com/qbittorrent/qBittorrent/commit/0ad52903890fe680307b46f4051bdd91d8aaffd5 I can confirm it builds fine with the github/website version, just not with the Gentoo ebuild.
(In reply to Michael Palimaka (kensington) from comment #6) > Does everyone else have ccache enabled too? I do not have ccache enabled. And yes, it looks as though this was fixed in a commit upstream, however the ebuild still does not work properly.
I have the same problem with net-p2p/qbittorrent-4.0.4[-X -dbus -debug -webui].
This is still not working with the latest ebuild (qbittorrent-4.1.1). As I have mentioned previously, there are no working ebuilds in the portage tree. What is the issue with getting a patched ebuild included in the tree?
Can confirm version 4.1.1 does not build with USE="webui -X -dbus -debug". Would it be possible to get a working version in the tree? There hasn't been a working version in the Portage tree for non X users in quite a long time. Unfortunately, I don't know cmake well enough to know what needs to be changed in the ebuild.
4.1.1 does not suffer from this. Which I will mark stable soon
Mikle, As I noted a couple comments up, the problem is still present in the version of qbittorrent 4.1.1 that is in the portage tree. Just to confirm I attempted to build it again just now with the same results, so I am going to re-open this.
(In reply to Chris Ribble from comment #13) > Mikle, > > As I noted a couple comments up, the problem is still present in the version > of qbittorrent 4.1.1 that is in the portage tree. > > Just to confirm I attempted to build it again just now with the same > results, so I am going to re-open this. can you provide your emerge --info and updated build.log then?
Created attachment 539560 [details] emerge --info
Created attachment 539562 [details] build.log
(In reply to Chris Ribble from comment #16) > Created attachment 539562 [details] > build.log Does /usr/include/qt5/QtSolutions folder (with all its content) exist in yout system? Also what does `file /usr/lib64/libQt5Solutions_SingleApplication-2.6.so` show?
(In reply to Mikle Kolyada from comment #17) > (In reply to Chris Ribble from comment #16) > > Created attachment 539562 [details] > > build.log > > Does /usr/include/qt5/QtSolutions folder (with all its content) exist in > yout system? > > Also what does `file /usr/lib64/libQt5Solutions_SingleApplication-2.6.so` > > show? coruscant ~ # ls -l /usr/include/qt5/QtSolutions/ total 12 -rw-r--r-- 1 root root 26 Apr 29 10:54 QtLockedFile -rw-r--r-- 1 root root 3244 Apr 29 10:54 qtlockedfile.h -rw-r--r-- 1 root root 2581 Apr 29 10:54 qtsinglecoreapplication.h coruscant ~ # file /usr/lib64/libQt5Solutions_SingleApplication-2.6.so /usr/lib64/libQt5Solutions_SingleApplication-2.6.so: symbolic link to libQt5Solutions_SingleApplication-2.6.so.1.0.0 coruscant ~ # file /usr/lib64/libQt5Solutions_SingleApplication-2.6.so.1.0.0 /usr/lib64/libQt5Solutions_SingleApplication-2.6.so.1.0.0: ELF 64-bit LSB pie executable x86-64, version 1 (SYSV), dynamically linked, stripped
(In reply to Chris Ribble from comment #18) > (In reply to Mikle Kolyada from comment #17) > > (In reply to Chris Ribble from comment #16) > > > Created attachment 539562 [details] > > > build.log > > > > Does /usr/include/qt5/QtSolutions folder (with all its content) exist in > > yout system? > > > > Also what does `file /usr/lib64/libQt5Solutions_SingleApplication-2.6.so` > > > > show? > > coruscant ~ # ls -l /usr/include/qt5/QtSolutions/ > total 12 > -rw-r--r-- 1 root root 26 Apr 29 10:54 QtLockedFile > -rw-r--r-- 1 root root 3244 Apr 29 10:54 qtlockedfile.h > -rw-r--r-- 1 root root 2581 Apr 29 10:54 qtsinglecoreapplication.h > > coruscant ~ # file /usr/lib64/libQt5Solutions_SingleApplication-2.6.so > /usr/lib64/libQt5Solutions_SingleApplication-2.6.so: symbolic link to > libQt5Solutions_SingleApplication-2.6.so.1.0.0 > > coruscant ~ # file /usr/lib64/libQt5Solutions_SingleApplication-2.6.so.1.0.0 > /usr/lib64/libQt5Solutions_SingleApplication-2.6.so.1.0.0: ELF 64-bit LSB > pie executable x86-64, version 1 (SYSV), dynamically linked, stripped Just to be finally sure, please also attach emerge --info dev-qt/qtsingleapplication and equery f dev-qt/qtsingleapplication
coruscant ~ # emerge --info dev-qt/qtsingleapplication --- SNIP --- dev-qt/qtsingleapplication-2.6.1_p20171024::gentoo was built with the following: USE="-X -doc" ABI_X86="(64)" coruscant ~ # equery f dev-qt/qtsingleapplication * Searching for qtsingleapplication in dev-qt ... * Contents of dev-qt/qtsingleapplication-2.6.1_p20171024: /usr /usr/include /usr/include/qt5 /usr/include/qt5/QtSolutions /usr/include/qt5/QtSolutions/qtsinglecoreapplication.h /usr/lib64 /usr/lib64/libQt5Solutions_SingleApplication-2.6.so -> libQt5Solutions_SingleApplication-2.6.so.1.0.0 /usr/lib64/libQt5Solutions_SingleApplication-2.6.so.1 -> libQt5Solutions_SingleApplication-2.6.so.1.0.0 /usr/lib64/libQt5Solutions_SingleApplication-2.6.so.1.0 -> libQt5Solutions_SingleApplication-2.6.so.1.0.0 /usr/lib64/libQt5Solutions_SingleApplication-2.6.so.1.0.0 /usr/lib64/qt5 /usr/lib64/qt5/mkspecs /usr/lib64/qt5/mkspecs/features /usr/lib64/qt5/mkspecs/features/qtsinglecoreapplication.prf /usr/share /usr/share/doc /usr/share/doc/qtsingleapplication-2.6.1_p20171024 /usr/share/doc/qtsingleapplication-2.6.1_p20171024/README.TXT.bz2
You probably need to build qtsingleapplication with USE=X
(In reply to Davide Pesavento from comment #21) > You probably need to build qtsingleapplication with USE=X True, because it wants qtsingleapplication.h as far as I can read CMakeList.txt
(In reply to Mikle Kolyada from comment #22) > (In reply to Davide Pesavento from comment #21) > > You probably need to build qtsingleapplication with USE=X > > True, because it wants qtsingleapplication.h as far as I can read > CMakeList.txt but also it wants only the only qtsinglecoreapplication.h otherwise, I see upstream GUI logic is being violated somehow (did not go deeper). So I think it is not our deal at all
Yes, it seems that dev-qt/qtsingleapplication is the culprit. I was able to change the two "use X && doins" in its ebuild to simply use "doins" and qbittorrent-4.1.1 builds correctly for me.
For those interested, I have submitted bug #661166 to try to resolve this.
(In reply to rypervenche from comment #24) > Yes, it seems that dev-qt/qtsingleapplication is the culprit. It is not. > I was able to > change the two "use X && doins" in its ebuild to simply use "doins" and > qbittorrent-4.1.1 builds correctly for me. Then simply enable USE=X as I already said (and fix the ebuild dependencies).
(In reply to Mikle Kolyada from comment #23) > (In reply to Mikle Kolyada from comment #22) > > (In reply to Davide Pesavento from comment #21) > > > You probably need to build qtsingleapplication with USE=X > > > > True, because it wants qtsingleapplication.h as far as I can read > > CMakeList.txt > > but also it wants only the only qtsinglecoreapplication.h otherwise, I see > upstream GUI logic is being violated somehow (did not go deeper). So I think > it is not our deal at all Not sure I understood your comment. If qbittorrent's build system looks for one header when it in fact needs a different one, that's an upstream bug.
(In reply to Davide Pesavento from comment #27) > (In reply to Mikle Kolyada from comment #23) > > (In reply to Mikle Kolyada from comment #22) > > > (In reply to Davide Pesavento from comment #21) > > > > You probably need to build qtsingleapplication with USE=X > > > > > > True, because it wants qtsingleapplication.h as far as I can read > > > CMakeList.txt > > > > but also it wants only the only qtsinglecoreapplication.h otherwise, I see > > upstream GUI logic is being violated somehow (did not go deeper). So I think > > it is not our deal at all > > Not sure I understood your comment. If qbittorrent's build system looks for > one header when it in fact needs a different one, that's an upstream bug. Yea, as I said nothing to do here for us
Closing a perfectly valid bug report is not going to make the problem disappear.
(In reply to Davide Pesavento from comment #21) > You probably need to build qtsingleapplication with USE=X Yes, I'm sure that would work, but I don't want to build with USE=X, as this is a headless system that does not have X installed and I do not want to install it. This works fine in qbittorrent-3.3.7 (no longer in portage, but I still have the binaries on my system since there hasn't been a working ebuild of any newer version).
(In reply to Chris Ribble from comment #30) > (In reply to Davide Pesavento from comment #21) > > You probably need to build qtsingleapplication with USE=X > > Yes, I'm sure that would work, but I don't want to build with USE=X, as this > is a headless system that does not have X installed and I do not want to > install it. I fully agree with you, that is not the proper solution, it's just a workaround. Can you please tell upstream about this problem, even better submit a patch? It's clear that gentoo maintainers don't have the resources to deal with this... TIA
(In reply to tudor from comment #7) > The issue has been fixed with this commit: > https://github.com/qbittorrent/qBittorrent/commit/ > 0ad52903890fe680307b46f4051bdd91d8aaffd5 > I can confirm it builds fine with the github/website version, just not > with the Gentoo ebuild. This has already been fixed upstream, as per my above comment. Only the portage tree needs to be updated to use this version.
(In reply to tudor from comment #32) > This has already been fixed upstream, as per my above comment. Only the > portage tree needs to be updated to use this version. What "version" are you talking about? That commit is already in 4.1.1, which is _not_ working according to Chris, so clearly it's not enough.
(In reply to Davide Pesavento from comment #33) > (In reply to tudor from comment #32) > > This has already been fixed upstream, as per my above comment. Only the > > portage tree needs to be updated to use this version. > What "version" are you talking about? That commit is already in 4.1.1, which > is _not_ working according to Chris, so clearly it's not enough. I can confirm that 4.1.1 still doesn't build in portage, but the github/site tarball builds fine.
you're probably not building against the system copy of qtsingleapplication
Steps I have tried: 1. Emerge qbittorrent (-X -dbus webui) on a headless system. 2. Let portage build all required dependencies (including qtsingleapplication). 3. Watch everything else build, except qbittorrent. 4. Download a tarball from the site (or github) and configure (without gui), make and make install. Source builds, no other deps used. This is not a Gentoo build problem, it was a qbittorrent problem (when built without X, where portage only (correctly) pulled only qtsingleapplication), but somehow the tarball in the tree doesn't contain the fix. From the patch comment: "This fixes cmake builds with GUI disabled and system QtSingleApplication. We rely on Qt5::Core instead of Qt5::Widgets."
PS: "3. Watch everything else build, except qbittorrent." means "it fails to configure", as per the original bug description.
(In reply to tudor from comment #36) > 4. Download a tarball from the site (or github) and configure (without gui), > make and make install. Source builds, no other deps used. Again, unless you pass -DSYSTEM_QTSINGLEAPPLICATION=ON to cmake, it will use the bundled copy of qtsingleapplication.
Please try newer version whis was commited just now. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c9307b1333310e9fe9474483bdf8b806c2d1537b The original bug comes from cmake buildsystem which I finally gave up on support, (even more, they do not recommend using cmake). It seems working fine right now even if you have compiled both qtsingleapplication and qbittorrent without X support.
Verified; 4.1.2 builds fine on my machine. Thanks!
