Created attachment 375196 [details] corrected ebuild qBittorent needs qtsingleapplication to have use X enabled, without it qtsingleapplication does not provide qtsingleapplication.h, which results in qbittorrent failing to build. Reproducible: Always Steps to reproduce: 1. USE="-X" emerge dev-qt/qtsingleapplication net-p2p/qbittorrent Expected result: Emerge should refuse to start and ask for USE change. Actual result: Emerge fails to build. Relevant part of failed build log: In file included from mainwindow.cpp:83:0: sessionapplication.h:39:33: fatal error: qtsingleapplication.h: No such file or directory #include "qtsingleapplication.h" ^ compilation terminated. Enabling 'X' use flag for dev-qt/qtsingleapplication lets build succeed. I include modified ebuild, that I think should work, though I haven't tested it.
Requiring X unconditionally is a mistake. It probably needs [X?]
Since you haven't provided a build.log, I assumed your build failure was because you were using qbittorrent with IUSE=X but you had qtsingleapplication compiled without it. This should be now fixed in tree.
Even in a case where I tried to compile qbittorrent with IUSE="-X", build failed if qtsingleapplication didn't have IUSE="X" enabled. Sorry that I didn't write it explicitly earlier, I though that `USE="-X" emerge dev-qt/qtsingleapplication net-p2p/qbittorrent` is equivalent.
Reopening. Please provide a full build log of the failed merge.
Created attachment 375344 [details] build.log for qbittorrent[-X]
Created attachment 375346 [details] build.log for qbittorrent[X] Previous build.log was for qbittorrent with USE="-X", missing piece: qtsinglecoreapplication.h This build.log is for qbittorrent with USE="X", missing piece: qtsingleapplication.h
(In reply to Zetok from comment #5) > Created attachment 375344 [details] > build.log This is a different problem. This one complains about qtsinglecoreapplication.h not the qtsingleapplication.h header.
(In reply to Markos Chandras from comment #7) > (In reply to Zetok from comment #5) > > Created attachment 375344 [details] > > build.log > > This is a different problem. This one complains about > qtsinglecoreapplication.h not the qtsingleapplication.h header. Davide am I correct to assume that qtsingleapplication should *not* need 'X' in order to provide 'qtsinglecoreapplication.h'. This feels wrong doesn't it?
(In reply to Markos Chandras from comment #8) > Davide am I correct to assume that qtsingleapplication should *not* need 'X' > in order to provide 'qtsinglecoreapplication.h'. Yes, that is correct, qtsinglecoreapplication.h is installed unconditionally.
(In reply to Davide Pesavento from comment #9) > (In reply to Markos Chandras from comment #8) > > Davide am I correct to assume that qtsingleapplication should *not* need 'X' > > in order to provide 'qtsinglecoreapplication.h'. > > Yes, that is correct, qtsinglecoreapplication.h is installed unconditionally. If that's true, then what's the problem in this bug? It seems like qtsingleapplication[X] is required even for qbittorrent[-X] because of the qtsinglecoreapplication.h
(In reply to Markos Chandras from comment #10) > (In reply to Davide Pesavento from comment #9) > > (In reply to Markos Chandras from comment #8) > > > Davide am I correct to assume that qtsingleapplication should *not* need 'X' > > > in order to provide 'qtsinglecoreapplication.h'. > > > > Yes, that is correct, qtsinglecoreapplication.h is installed unconditionally. > > If that's true, then what's the problem in this bug? It seems like > qtsingleapplication[X] is required even for qbittorrent[-X] because of the > qtsinglecoreapplication.h I think that the problem is in the src.pro file: usesystemqtsingleapplication { nox { CONFIG += qtsinglecoreapplication } else { CONFIG += qtsingleapplication } } else { should probably become just usesystemqtsingleapplication { nox { CONFIG += qtsingleapplication } } else { ... because as far as I can tell, and I would be guessing here, it seems that the two packages qtsinglecoreapplication and qtsingleapplication were merged into dev-qt/qtsingleapplication. So dev-qt/qtsingleapplication is always needed an a bug might need to be file upstream.
(In reply to cjanderson from comment #11) > because as far as I can tell, and I would be guessing here, it seems that > the two packages qtsinglecoreapplication and qtsingleapplication were merged > into dev-qt/qtsingleapplication. So dev-qt/qtsingleapplication is always > needed an a bug might need to be file upstream. Pulling dev-qt/qtsingleapplication is not a problem as long as it does not require [X] if X is disabled on qbittorrent. I feel there is something wrong with our qtsingleapplication package.
The build logs are useless, they don't show compiler command lines.
Zetok, remove -s from your MAKEOPTS and do *NOT* add it again, ever, unless you want all your bugs closed as INVALID or NEEDINFO.
The problem is that qbittorrent[-X] wants to load qtsinglecoreapplication.prf but it fails because we install only qtsingleapplication.prf. Actually I'm not sure where that file comes from since it's not present in the repository... Anyway, I'll fix this soon.
(In reply to Davide Pesavento from comment #15) > The problem is that qbittorrent[-X] wants to load > qtsinglecoreapplication.prf but it fails because we install only > qtsingleapplication.prf. Actually I'm not sure where that file comes from > since it's not present in the repository... > > Anyway, I'll fix this soon. I believe that qtsinglecoreapplication.prf has gone the way of the dodo. The header file can be found in qtsingleapplication.prf. Why not just lodge a bug upstream? What do you make of this: host ~ # q belongs /usr/share/qt4/mkspecs/features/qtsingleapplication.prf dev-qt/qtsingleapplication host ~ # q files dev-qt/qtsingleapplication /usr/include/qt4/QtSolutions/qtsinglecoreapplication.h /usr/share/qt4/mkspecs/features/qtsingleapplication.prf /usr/lib64/libQtSolutions_SingleApplication-2.6.so.1.0.0 /usr/lib64/libQtSolutions_SingleApplication-2.6.so /usr/lib64/libQtSolutions_SingleApplication-2.6.so.1.0 /usr/lib64/libQtSolutions_SingleApplication-2.6.so.1 Isn't this the singlecoreapplication?
(In reply to cjanderson from comment #16) > I believe that qtsinglecoreapplication.prf has gone the way of the dodo. The > header file can be found in qtsingleapplication.prf. Why not just lodge a > bug upstream? > Maybe. Maybe not. Given that the upstream package doesn't have *any* .prf file, there's no right or wrong here... What do other distros do? > What do you make of this: > > host ~ # q belongs /usr/share/qt4/mkspecs/features/qtsingleapplication.prf > dev-qt/qtsingleapplication > > host ~ # q files dev-qt/qtsingleapplication > /usr/include/qt4/QtSolutions/qtsinglecoreapplication.h > /usr/share/qt4/mkspecs/features/qtsingleapplication.prf > /usr/lib64/libQtSolutions_SingleApplication-2.6.so.1.0.0 > /usr/lib64/libQtSolutions_SingleApplication-2.6.so > /usr/lib64/libQtSolutions_SingleApplication-2.6.so.1.0 > /usr/lib64/libQtSolutions_SingleApplication-2.6.so.1 > > Isn't this the singlecoreapplication? What's your point?
> > I believe that qtsinglecoreapplication.prf has gone the way of the dodo. The > > header file can be found in qtsingleapplication.prf. Why not just lodge a > > bug upstream? > > > > Maybe. Maybe not. Given that the upstream package doesn't have *any* .prf > file, there's no right or wrong here... What do other distros do? Most probably build never build without the no-gui option. See gentoo is special here. > > What do you make of this: > > > > host ~ # q belongs /usr/share/qt4/mkspecs/features/qtsingleapplication.prf > > dev-qt/qtsingleapplication > > > > host ~ # q files dev-qt/qtsingleapplication > > /usr/include/qt4/QtSolutions/qtsinglecoreapplication.h > > /usr/share/qt4/mkspecs/features/qtsingleapplication.prf > > /usr/lib64/libQtSolutions_SingleApplication-2.6.so.1.0.0 > > /usr/lib64/libQtSolutions_SingleApplication-2.6.so > > /usr/lib64/libQtSolutions_SingleApplication-2.6.so.1.0 > > /usr/lib64/libQtSolutions_SingleApplication-2.6.so.1 > > > > Isn't this the singlecoreapplication? > What's your point? Isn't this what you are looking for? Isn't this the cause of the error? Just change the pro file as suggested, which is what I have been doing for most of this year since I first noticed this problem but could not be bothered fixing it myself. Honestly, I have seen at least 3 new versions of qbittorrent with this same problem.
I just committed qtsingleapplication-2.6.1_p20130904-r1, which installs qtsinglecoreapplication.prf
Fixed in 3.1.9.2-r1
