Description of problem: lximage-qt fails to build from source for Fedora EPEL7 on RHELSA-7.2. Version-Release number of selected component (if applicable): lximage-qt-0.5.0-1.el7 How reproducible: consistently Steps to Reproduce: 1. On a RHELSA-7.2 host: mock rebuild lximage-qt-0.5.0-1.el7.src.rpm 2. 3. Actual results: Fails to build with the following error: Error: Package: liblxqt-0.11.0-1.el7.aarch64 (epel) Requires: libQt5Xdg.so.1()(64bit) Available: libqtxdg-1.3.0-2.el7.aarch64 (epel) libQt5Xdg.so.1()(64bit) Installing: libqtxdg-2.0.0-2.el7.aarch64 (local) ~libQt5Xdg.so.2()(64bit) Expected results: builds without errors. Additional info: If I remove libqtxdg-2.0.0-2.el7.aarch64 (recently released) from the buildroot and instead use the previous version (libqtxdg-1.3.0-2.el7), I no longer get this error, but instead get the following error: CMake Error at CMakeLists.txt:21 (find_package): By not providing "FindQt5Svg.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "Qt5Svg", but CMake did not find one. Could not find a package configuration file provided by "Qt5Svg" with any of the following names: Qt5SvgConfig.cmake qt5svg-config.cmake Add the installation prefix of "Qt5Svg" to CMAKE_PREFIX_PATH or set "Qt5Svg_DIR" to a directory containing one of the above files. If "Qt5Svg" provides a separate development package or SDK, be sure it has been installed. -- Configuring incomplete, errors occurred! It appears that x86_64 pulls in the following dependencies: DEBUG util.py:421: qt5-qtsvg x86_64 5.6.1-2.el7 DEBUG util.py:421: qt5-qtsvg-devel x86_64 5.6.1-2.el7 but AArch64 does not. This is not an explicit build dependency for lximage-qt, and I'm not sure what pulls it in, but that appears to be missing for AArch64. If I manually install qt5-qtsvg-devel and qt5-qtsvg in the mock buildroot (still using libqtxdg-1.3.0-2.el7), the build completes without error.
David, It sounds like this is an issue with the liblxqt in your buildroot. The official EPEL liblxqt-0.11.0-1.el7 was built with libqtxdg-2.0: http://koji.fedoraproject.org/koji/rpminfo?rpmID=8118462 https://kojipkgs.fedoraproject.org//packages/liblxqt/0.11.0/1.el7/data/logs/x86_64/root.log IOW, libqtxdg-2.0 was built first and put in a build override, then liblxqt was built, followed by lximage-qt. This is part of the "magic" of koji-shadow that you have to work around yourself when you're building manually. HTH.
I think the bug is valid. https://github.com/lxde/lximage-qt/commit/2643ece49a62ad500514942ad02725180003fb80 That's a new change for 0.5.0, we forgot to add the new BuildRequires with the recent update. The strange point here is why it builds on x86_64 anyways.
(In reply to Raphael Groner from comment #2) > I think the bug is valid. Not really, the issue you raise below is separate. > https://github.com/lxde/lximage-qt/commit/ > 2643ece49a62ad500514942ad02725180003fb80 > > That's a new change for 0.5.0, we forgot to add the new BuildRequires with > the recent update. The strange point here is why it builds on x86_64 anyways. Because libqtxdg-devel already pulls it in: http://koji.fedoraproject.org/koji/rpminfo?rpmID=8119775 Now that's not to say that this implicit BR shouldn't be fixed, but the OP will still need to rebuild the hand-built packages in the correct dependency order, otherwise more such issues will arise.
(In reply to Yaakov Selkowitz from comment #3) … > Now that's not to say that this implicit BR shouldn't be fixed, but the OP > will still need to rebuild the hand-built packages in the correct dependency > order, otherwise more such issues will arise. Sure. That was my first guess into the blue sky, too. In my opinion, it's better to explicitly follow in the spec file as the cmake direct dependencies are set by upstream, to avoid things like that happening with implicit build dependencies.
Reversing the build order of liblxqt-0.11.0-1 and libqtxdg-2.0.0-2 does indeed allow lximage-qt-0.5.0-1 to build without errors. Thank you for identifying the issue.
Fixed in rawhide. Please let me know if you need the fix also in other Fedora versions.