I will update the spec, so that future builds on epel8 use a newer toolset, but I will not hold off this entire release of these packages for it. As kkofler said "What does it matter?"
If you have a legitimate "It doesn't work" or "There is a security issue" then I would certainly hold things off. But simply "it's old" doesn't really carry any weight.
This update can be pushed to stable now if the maintainer wishes
kio-extras is a separate package, it can in principle be pushed separately. But of course the versions should match. In the end, @tdawson will have to decide whether to edit the update with the new build, resetting the karma and time counters, or push a followup update.
(This is one of the cases where the current Fedora update policy just fails us. Without those Bodhi-enforced rules, we could just edit the update with the added build and queue it directly to stable anyway, because 99.7% of the builds in it would still have been tested sufficiently, and the one added build is a regression fix. But unfortunately, the EPEL steering committee wants those annoying rules even more than Fedora FESCo does, and FESCo already wants them a lot.)
(By the way, for a long time, there used to be a glitch in Bodhi where it would have been possible to first click "Push to stable" and then edit in the new build, bypassing the check, but I believe this has unfortunately been fixed at some point, either automatically canceling the stable push request or locking the update to prevent adding builds unless the request is manually canceled first.)
For me it's fine when kio-extras is in a separate build. Perhaps we can enable stable by karma for that build.
I just tried build it locally, from the EPEL9 srpm, but it seems we have outdated dependencies in EPEL8. Which might also be the cause why it is not in this build. Because for EPEL9 kio-extras is in the same build as the rest of KDE.
Well, then I guess we should try rebuilding the old kio-extras against the current Qt5 from RHEL8 and the current KF5 from this build. Because a rebuild seems clearly needed.
kio-extras indeed fell through the cracks. My apologies.
The updated kio-extras needs kdsoap to build. Although I built kdsoap for epel9, and thus kio-extras for epel9-next, it never got put on my list of things to do for epel8.
I'm working on it right now. A weird docs issue with kdsoap, but I hope to have the updated kio-extras in it's own update today.
This update has been submitted for stable by tdawson.
Now that I try building it again, I remember why I couldn't build it on epel8. You get errors like these
In file included from /usr/include/OpenEXR/ImfHeader.h:51,
from /builddir/build/BUILD/kio-extras-22.04.1/thumbnail/exrcreator.cpp:15:
/usr/include/OpenEXR/ImathVec.h:228:41: error: ISO C++17 does not allow dynamic exception specifications
228 | const Vec2 & normalizeExc () throw (IEX_NAMESPACE::MathExc);
| ^~~~~
I still think this update can/should go to stable. But I'd appreciate if you opened a bug about kio-extras.
I'm betting this is an openexr bug, which is in RHEL 8. It would be good if I had a bug I could point to while working with the maintainer.
This update has been submitted for testing by tdawson.
This update's test gating status has been changed to 'ignored'.
This update has been pushed to testing.
Seems to be working fine for me.
kf5-kio is build with gcc-toolset-9 which is already EOL. Please rebuild with at least gcc-toolset-11 (oldest toolset still suppoted).
Unfortunately it looks like gcc-toolset-10 which is already EOL is latest one which works for kf5-kio build.
Why does that matter? As far as I can tell, it does not have any runtime dependencies on the toolset.
I will update the spec, so that future builds on epel8 use a newer toolset, but I will not hold off this entire release of these packages for it. As kkofler said "What does it matter?"
If you have a legitimate "It doesn't work" or "There is a security issue" then I would certainly hold things off. But simply "it's old" doesn't really carry any weight.
This update can be pushed to stable now if the maintainer wishes
For SMB shares in dolphin don't work after the update. They are shown empty. Can someone confirm?
For me it looks like kio-extras is missing in this build, this might cause my SMB problem.
kio-extras is a separate package, it can in principle be pushed separately. But of course the versions should match. In the end, @tdawson will have to decide whether to edit the update with the new build, resetting the karma and time counters, or push a followup update.
(This is one of the cases where the current Fedora update policy just fails us. Without those Bodhi-enforced rules, we could just edit the update with the added build and queue it directly to stable anyway, because 99.7% of the builds in it would still have been tested sufficiently, and the one added build is a regression fix. But unfortunately, the EPEL steering committee wants those annoying rules even more than Fedora FESCo does, and FESCo already wants them a lot.)
(By the way, for a long time, there used to be a glitch in Bodhi where it would have been possible to first click "Push to stable" and then edit in the new build, bypassing the check, but I believe this has unfortunately been fixed at some point, either automatically canceling the stable push request or locking the update to prevent adding builds unless the request is manually canceled first.)
For me it's fine when kio-extras is in a separate build. Perhaps we can enable stable by karma for that build.
I just tried build it locally, from the EPEL9 srpm, but it seems we have outdated dependencies in EPEL8. Which might also be the cause why it is not in this build. Because for EPEL9 kio-extras is in the same build as the rest of KDE.
Well, then I guess we should try rebuilding the old kio-extras against the current Qt5 from RHEL8 and the current KF5 from this build. Because a rebuild seems clearly needed.
kio-extras indeed fell through the cracks. My apologies. The updated kio-extras needs kdsoap to build. Although I built kdsoap for epel9, and thus kio-extras for epel9-next, it never got put on my list of things to do for epel8. I'm working on it right now. A weird docs issue with kdsoap, but I hope to have the updated kio-extras in it's own update today.
This update has been submitted for stable by tdawson.
Now that I try building it again, I remember why I couldn't build it on epel8. You get errors like these
I still think this update can/should go to stable. But I'd appreciate if you opened a bug about kio-extras. I'm betting this is an openexr bug, which is in RHEL 8. It would be good if I had a bug I could point to while working with the maintainer.
As a quick hack to work around the bad header, try:
Thank you very much. It needed one other tweak but you got me on the right place. The updated kio-extras is built. It's not yet in -testing, but here is it's bodhi update. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-040ea10be7
This update has been pushed to stable.