Dear package maintainer, This is an automated bug created due to a FTBFS when rebuilding this package for the change proposal CMake: Use ninja generator by default. The rebuild is being tracked in https://copr.fedorainfracloud.org/coprs/lecris/cmake-ninja/package/mosquitto. See https://fedoraproject.org/wiki/Changes/CMake_ninja_default for more information on how to make the package compatible. More specifically, make sure you are using standard %cmake_* macros. If you find that there are hard dependencies on the generator even after such transition, please ping me for closer investigation. You can check the build locally following the instructions in the change proposal, or submit your build to the tracking copr project. Let me know if you encounter any issues, or need any other help.
AFAICT I am using standard %cmake_ macros and it's not clear from this bug report what the problem is, please provide actual useful information as to what you actually expect me to do or why it would be FTB.
The pushd popd are no longer necessary and I am not sure how it interacts with the manually provided `-S` and `-B` flags (I think the former is not provided so that's why it still works) But for the reported issue it seems to be ``` [173/186] cd /builddir/build/BUILD/mosquitto-2.0.22-build/mosquitto-2.0.22/build/redhat-linux-build/man && xsltproc /builddir/build/BUILD/mosquitto-2.0.22-build/mosquitto-2.0.22/man/mosquitto_ctrl.1.xml -o /builddir/build/BUILD/mosquitto-2.0.22-build/mosquitto-2.0.22/man/ FAILED: /builddir/build/BUILD/mosquitto-2.0.22-build/mosquitto-2.0.22/man/mosquitto_ctrl.1 cd /builddir/build/BUILD/mosquitto-2.0.22-build/mosquitto-2.0.22/build/redhat-linux-build/man && xsltproc /builddir/build/BUILD/mosquitto-2.0.22-build/mosquitto-2.0.22/man/mosquitto_ctrl.1.xml -o /builddir/build/BUILD/mosquitto-2.0.22-build/mosquitto-2.0.22/man/ error : Resource temporarily unavailable warning: failed to load external entity "http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl" compilation error: file /builddir/build/BUILD/mosquitto-2.0.22-build/mosquitto-2.0.22/man/manpage.xsl line 3 element import xsl:import : unable to load http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl compilation error: file /builddir/build/BUILD/mosquitto-2.0.22-build/mosquitto-2.0.22/man/mosquitto_ctrl.1.xml line 4 element refentry xsltParseStylesheetProcess : document is not a stylesheet ``` (the issues seems to be that `xsltproc` is trying to access a file from the internet while in koji build) I looked in the koji builds log but I couldn't find any references for it doing the same logic: ``` gmake[2]: Nothing to be done for 'man/CMakeFiles/mosquitto_ctrl.1.dir/build'. ``` It seems that during the installation it is instructed to write to and install from the source files. Normally it should skip the creation if the file is already present, but I believe ninja also looks for a timestamp file which is not present at first build so with the ninja generator it does run it, but with the makefile generator it only checks for the presence of the files. There are some other things that are dubious like the `install(FILES)` is gated even though the files are always present in the source. It is hard to tell what the upstream intent and state of those files are, so could you open an issue upstream? Feel free to tag me if upstream needs more details. To give a reproducible for upstream, have them apply ``` diff -ru mosquitto-2.0.22/man/CMakeLists.txt mosquitto-2.0.22-new/man/CMakeLists.txt --- mosquitto-2.0.22/man/CMakeLists.txt 2025-07-11 23:32:27.000000000 +0200 +++ mosquitto-2.0.22-new/man/CMakeLists.txt 2025-07-18 11:52:00.702546686 +0200 @@ -8,7 +8,7 @@ if(XSLTPROC AND NOT WIN32) function(compile_manpage page) add_custom_command(OUTPUT ${PROJECT_SOURCE_DIR}/man/${page} - COMMAND xsltproc ${PROJECT_SOURCE_DIR}/man/${page}.xml -o ${PROJECT_SOURCE_DIR}/man/ + COMMAND ${CMAKE_COMMAND} -E false MAIN_DEPENDENCY ${PROJECT_SOURCE_DIR}/man/${page}.xml) add_custom_target(${page} ALL DEPENDS ${PROJECT_SOURCE_DIR}/man/${page}) endfunction() ``` and try to run them with both Makefile and Ninja, and see if one fails and the other doesn't.
Oh, please read this warning message: ``` + /usr/bin/cmake -S . -B redhat-linux-build -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF -DCMAKE_INSTALL_PREFIX:PATH=/usr -DCMAKE_INSTALL_FULL_SBINDIR:PATH=/usr/bin -DCMAKE_INSTALL_SBINDIR:PATH=bin -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64 -DBUILD_SHARED_LIBS:BOOL=ON -DCMAKE_INSTALL_LIBDIR=/usr/lib64 -DCMAKE_INCLUDE_PATH=/usr/include/libmetal/ -DCMAKE_LIBRARY_PATH=/usr/lib64 -DWITH_STATIC_LIB=OFF -DWITH_APPS=ON .. CMake Warning: Ignoring extra path from command line: ".." ``` The pushd popd may actually be an issue. Not the issue for this error, but an issue to address nonetheless imo
The pushd/popd have never been an issue in the past, and they're supported generally in rpm. So I suspect if they're are a problem it's spurious and masking a problem elsewhere. None the less, I have dropped them and done a rawhide build so please recheck.
Thanks, the configure log looks much cleaner. I did find this issue as well, which you might want to raise with libwebsockets maintainers: ``` CMake Warning at src/CMakeLists.txt:144 (find_package): By not providing "Findlibwebsockets.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "libwebsockets", but CMake did not find one. Could not find a package configuration file provided by "libwebsockets" with any of the following names: libwebsocketsConfig.cmake libwebsockets-config.cmake Add the installation prefix of "libwebsockets" to CMAKE_PREFIX_PATH or set "libwebsockets_DIR" to a directory containing one of the above files. If "libwebsockets" provides a separate development package or SDK, be sure it has been installed. ``` They seem to be explictly removing the CMake files [1]. Probably it still works just because CMake has a fallbacks that work on system packages, but it can break in the future. Anyway regarding the original issue, do you wish to raise the issue with upstream? You can still work around it by explicitly using the Makefile generator ``` %global _cmake_generator "Unix Makefiles" ``` [1]: https://src.fedoraproject.org/rpms/libwebsockets/blob/rawhide/f/libwebsockets.spec#_100
I fixed the libwebsockets issue.