Bug 1557223

To clarify:
The upstream release and prior Fedora RPMs do not require libX11 etc to be installed.  The current Fedora RPM does.

qbittorrent-nox has no X11 dep

$ rpm -qp --requires qbittorrent-nox-4.0.4-1.fc27.x86_64.rpm 
/bin/bash
ld-linux-x86-64.so.2()(64bit)
ld-linux-x86-64.so.2(GLIBC_2.3)(64bit)
libQt5Core.so.5()(64bit)
libQt5Core.so.5(Qt_5)(64bit)
libQt5Core.so.5(Qt_5.9)(64bit)
libQt5Network.so.5()(64bit)
libQt5Network.so.5(Qt_5)(64bit)
libQt5Solutions_SingleCoreApplication-2.6.so.1()(64bit)
libQt5Xml.so.5()(64bit)
libQt5Xml.so.5(Qt_5)(64bit)
libboost_system.so.1.64.0()(64bit)
libc.so.6()(64bit)
libc.so.6(GLIBC_2.14)(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libgcc_s.so.1()(64bit)
libgcc_s.so.1(GCC_3.0)(64bit)
libm.so.6()(64bit)
libm.so.6(GLIBC_2.2.5)(64bit)
libpthread.so.0()(64bit)
libpthread.so.0(GLIBC_2.2.5)(64bit)
libstdc++.so.6()(64bit)
libstdc++.so.6(CXXABI_1.3)(64bit)
libstdc++.so.6(CXXABI_1.3.7)(64bit)
libstdc++.so.6(GLIBCXX_3.4)(64bit)
libstdc++.so.6(GLIBCXX_3.4.11)(64bit)
libstdc++.so.6(GLIBCXX_3.4.14)(64bit)
libstdc++.so.6(GLIBCXX_3.4.15)(64bit)
libstdc++.so.6(GLIBCXX_3.4.18)(64bit)
libstdc++.so.6(GLIBCXX_3.4.19)(64bit)
libstdc++.so.6(GLIBCXX_3.4.21)(64bit)
libstdc++.so.6(GLIBCXX_3.4.9)(64bit)
libtorrent-rasterbar.so.9()(64bit)
libz.so.1()(64bit)
libz.so.1(ZLIB_1.2.0)(64bit)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1
rtld(GNU_HASH)

why is this bug assigned to qtsingleapplication?

It appears the fix from last time was to qtsingleapplication.  You can read about it at https://github.com/qbittorrent/qBittorrent/issues/4829#issuecomment-187379970

I am guessing the bug was assigned to qtsingleapplication because the qt5-qtbase package and the X11 dependencies are getting pulled in through the qtsingleapplication-qt5 (*) dependency. This wasn't the case years ago when I packaged qtsingleapplication for qt4. Leigh can clarify if this is inaccurate.

(*) libQt5Solutions_SingleCoreApplication-2.6.so.1()(64bit) is provided by qtsingleapplication-qt5

correction: Please replace qtsingleapplication-qt5 with qtsinglecoreapplication-qt5 in the previous message.

(In reply to Orcan Ogetbil from comment #5)
> I am guessing the bug was assigned to qtsingleapplication because the
> qt5-qtbase package and the X11 dependencies are getting pulled in through
> the qtsingleapplication-qt5 (*) dependency. This wasn't the case years ago
> when I packaged qtsingleapplication for qt4. Leigh can clarify if this is
> inaccurate.
> 

That is accurate, thank you for clarifying.

> (*) libQt5Solutions_SingleCoreApplication-2.6.so.1()(64bit) is provided by
> qtsingleapplication-qt5

I still fail to understand what's the issue.

The mentioned dependency is there since ages:
https://src.fedoraproject.org/rpms/qtsingleapplication/blob/master/f/qtsingleapplication.spec#_96

Are you sure about correct unbundling? Upstream sources of qbittorrent provide their own qtsingleapplication:
https://github.com/qbittorrent/qBittorrent/tree/master/src/app/qtsingleapplication

Reassigning back. Please feel free to reassign again if you're sure the bug is in the separate package qtsingleapplication.

* Thu Jul 22 2010 Leigh Scott <leigh123linux> - 2.3.0-0.10.rc7
- add Br qtsinglecoreapplication-devel
- add patch so nox uses qtsinglecoreapplication

Does that patch still work?

(In reply to Raphael Groner from comment #8)
> I still fail to understand what's the issue.
> 
> The mentioned dependency is there since ages:
> https://src.fedoraproject.org/rpms/qtsingleapplication/blob/master/f/
> qtsingleapplication.spec#_96
> 
> Are you sure about correct unbundling? Upstream sources of qbittorrent
> provide their own qtsingleapplication:
> https://github.com/qbittorrent/qBittorrent/tree/master/src/app/
> qtsingleapplication
> 
> Reassigning back. Please feel free to reassign again if you're sure the bug
> is in the separate package qtsingleapplication.

Don't play dumb just fix your package!!!!!

Investigating this further, I see that the X11 dependencies are pulled in through the libQt5EglFSDeviceIntegration.so* that comes with qt5-qtbase.

qtsinglecoreapplication needs other files from qt5-qtbase, e.g. libQt5Core.so*, but not the libQt5EglFSDeviceIntegration.so*

This request needs to be handled on the qt5-qtbase side.

qt5 maintainer,
Please advise if it is possible to ship qt5-qtbase without the X11 dependency, by moving libQt5EglFSDeviceIntegration.so* to some other (sub)package.

That likely should be in qt5-qtbase-gui, moving it should not be a problem.

(rawhide)
%changelog
* Wed May 30 2018 Rex Dieter <rdieter> - 5.11.0-2
- move libQt5EglFSDeviceIntegration to -gui (#1557223)

Wonderful. Thank you Rex. This should resolve the original problem, unless we missed something else.

Is it possible to backport this fix to el7?  Yum is trying to install 38 dependances (the X11 libs) to upgrade qt5-qtbase from 5.6.2-1.el7 to 5.9.2-3.el7.  Thank you.

qt5 is a core rhel7 package now, you'll have to contact rhel support (or file a separate bug against rhel)

qt5-qtbase-5.9.6-4.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-fb5a8bfa34

qt5-qtbase-5.9.6-4.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-fb5a8bfa34

qt5-qtbase-5.9.6-4.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.