I am testing rebuilds of all packages dependent on OpenEXR as the latest version has move from autotools to CMake and now has ilmbase built in. https://copr.fedorainfracloud.org/coprs/hobbes1069/openexr/build/1829270/ kdelibs appears to be FTBFS probably due to gcc 11 which finds new errors? /builddir/build/BUILD/kdelibs-4.14.38/kdecore/localization/klocale_kde.cpp: In member function 'virtual bool KLocalePrivate::use12Clock() const': /builddir/build/BUILD/kdelibs-4.14.38/kdecore/localization/klocale_kde.cpp:2441:59: error: ordered comparison of pointer with integer zero ('const void*' and 'int') 2441 | if ((timeFormat().contains(QString::fromLatin1("%I")) > 0) || | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~ /builddir/build/BUILD/kdelibs-4.14.38/kdecore/localization/klocale_kde.cpp:2442:59: error: ordered comparison of pointer with integer zero ('const void*' and 'int') 2442 | (timeFormat().contains(QString::fromLatin1("%l")) > 0)) { | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~ /builddir/build/BUILD/kdelibs-4.14.38/kdecore/localization/klocale_kde.cpp:2447:1: warning: control reaches end of non-void function [-Wreturn-type] 2447 | } | ^
This code is a leftover from Qt 3 times: In Qt 3, QString::contains returned an int, the number of times the character occurs in the string. In Qt 4, QString::contains was changed to return a bool instead (which is still the case in Qt 5). The fix is to remove the "> 0" in both lines. This bug is still present in the copy of the code in KF5 kdelibs4support: https://invent.kde.org/frameworks/kdelibs4support/-/blob/ff85d52bb12300cceb30492b2aff3e4692644e1c/src/kdecore/klocale_kde.cpp#L2125
This should be fixed now as well as a minor const-correctness issue.
Well, the != 0 checks don't really make sense semantically because contains actually returns a boolean. What happens there is that the Qt methods actually return a magic internal class that implicitly converts to both bool and void *, exactly so that legacy code that has explicit != 0 checks still works (and with GCC < 11, one got away even with > 0 checks), but it's still legacy. :-)
That's the most direct fix without changing the meaning of the existing code. Someone with a better understanding of the QT interfaces may well have a better fix.