Summary: | net-p2p/qbittorrent-4.1.1 cannot find QtSingleApplication | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Chris Ribble <astor84> |
Component: | Current packages | Assignee: | Mikle Kolyada (RETIRED) <zlogene> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | astor84, contact, jstein, qt, silver_ghost, tudor.mihu |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://github.com/qbittorrent/qBittorrent/issues/9196 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
emerge --info
build.log build.log ebuild that works for me emerge --info build.log |
Description
Chris Ribble
2017-12-04 06:18:05 UTC
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! |