FYI, the differences between 2.4.1-2 and 2.4.1-3 are: "the checkbox for LUKS full disk encryption with automatic partitioning was hidden, because this feature (added in Calamares 2.3) is unfortunately not working on Fedora (with dracut) yet," and "the menu item now uses kdesu instead of pkexec to obtain root privileges, because pkexec breaks Qt's desktop integration."

FYI, the difference between 2.4.1-1 and 2.4.1-2 is this: "a regression in Calamares 2.4/2.4.1 was fixed: the locale module was filtering out all locales, resulting in an empty list, because it was not recognizing .utf8 locales as UTF-8".

FYI, the difference between 2.4.1-1 and 2.4.1-2 is this: "a regression in Calamares 2.4/2.4.1 was fixed: the locale module was filtering out all locales, resulting in an empty list, because it was not recognizing .utf8 locales as UTF-8".

This cannot possibly fix #1377017, see the comment I added there.

I just added the ID of the bug that was newly filed (#1327413).

Thank you for the feedback, but please note that this update cannot be pushed to stable as long as Qt 5.6 is stuck in testing.

https://github.com/fedora-infra/bodhi/issues/772

Meh… In Bodhi 1, one could set the auto-karma to 1 for updates with karma 1 and then it'd let you push it manually immediately. Now there appears to be no way to trigger the push, but if you had the auto-karma at 1 to begin with, then it would happily push it. So you get punished for wanting to verify the feedback you get. This is really asinine.

Trying to trigger the auto-karma push.

Trying to trigger the auto-karma push.

Works fine on svn.calcforge.org (CentOS 7). The broken dependency is fixed now.

Works fine here (except that kdelibs 4.14.12 claims to be 4.14.11, but that does not impact functionality).

obsoleted by kdevelop-4.7.1-10.fc22, which should fix the regression

This update has been unpushed.

I disabled the autokarma nonsense and resent the update to testing.

Uh, konsole5 wasn't rebuilt. You probably just upgraded your qt5 to 5.5.

(By the way, why aren't we using dedicated build targets for Qt upgrades anymore, especially now with Qt 5 split packaging? Putting Qt into buildroot overrides used to cause lots of issues like this in the past, which is why we had stopped doing that.)

rdieter, you need to expire the Qt 5.5 buildroot overrides and rebuild this, or add this to the 5.5 update group.

Any chance we can figure out what is going wrong here? jgrulich, do you have a backtrace? We cannot withhold all KDevelop updates forever. We've already been sitting on this regression fix for over 2 weeks.