Description of problem: Currently it's not possible to use CMake to find libical (using CMake config files, i.e. via find_package(LibIcal ....) command), because the package is missing static libraries: CMake Error at /usr/lib64/cmake/LibIcal/LibIcalTargets.cmake:76 (message): The imported target "ical-static" references the file "/usr/lib64/libical.a" but this file does not exist. Possible reasons include: * The file was deleted, renamed, or moved to another location. * An install or uninstall procedure did not complete successfully. * The installation package was faulty and contained "/usr/lib64/cmake/LibIcal/LibIcalTargets.cmake" but not all the files it references. Since libical is built with static libraries enabled, the generated CMake config files are referencing the libical-static target. Because CMake verifies all imported targets, the configuration fails because the files are not found. There should either be libical-static subpackage with the static files or if you really don't want to build the static files you must pass -DSHARED_ONLY=TRUE to CMake to disable the static libraries. It will also make sure the generated CMake config files don't reference the libical-static target anymore.
%changelog * Mon Feb 01 2016 Rex Dieter <rdieter> 2.0.0-4 - %%build: -DSHARED_ONLY=TRUE (#1303598)
oops, looks like f23 is needed too, re-opening
nevermind, looks like bug had wrong version, re-closing (marking rawhide).
Event with disabled static libraries, looking into the installed cmake files I see that LibIcalConfig.cmake still references static parts partly: > # Temporary, will be removed once issue#87 is fixed > set(LibIcal_STATIC_LIBRARIES ical-static icalss-static icalvcal-static) The other files are free of the 'static' when built with SHARED_ONLY. I'm unsure whether SHARED_ONLY=true will be sufficient for your build in this case (aka should there be added also a patch which will remove the above quoted lines to make it work properly?).
simply setting a variable should be mostly harmless, unless... is LibIcal_STATIC_LIBRARIES actually used anywhere else? (if not, it's fine)
I was right, we did need this fixed for f23 too (I just hit FTBFS), doing so now.
libical-1.0.1-3.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-d938b80157
libical-1.0.1-3.fc23 has been pushed to the Fedora 23 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-2016-d938b80157
libical-1.0.1-3.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2016-72a831c739
libical-1.0.1-3.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
libical-1.0.1-3.fc22 has been pushed to the Fedora 22 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-2016-72a831c739
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle. Changing version to '24'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
libical-1.0.1-3.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.