A perfectly fair comment. However I didn't choose to install prrte, it came in during the F40 upgrade for some reason.

I will raise a bug for the prrte package, feel free to withdraw my negative karma, I suppose I should have made it neutral.

It seems that one of the recent commits here:

https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/commits/master

has deliberately removed compatibility with various older icon formats.

Seeing this with gnome-usage update attempt

Problem: cannot install the best update candidate for package gnome-usage-45.0-1.fc40.x86_64 - nothing provides libadwaita >= 1.5 needed by gnome-usage-46.0-1.fc40.x86_64 from updates-testing

Installed version of libadwaita is this:

libadwaita-1.5~beta-1.fc40.x86_64

Probably a libadwaita update is in the works, but not in koji yet.

This now installs with the kde-connect update.

gnome-applets and gnome-flashback have now been rebuilt against kernel-tools-6.6.2-200 and are fine.

Looks like other packages that depend on libcpupower.so files will need the same rebuild.

kernel-tools-libs appears to have changed the libcpupower.so.0 to .so.1, however the underlying .so.0.0.1 is the same version as in the previous kernel-tools version.

This looks like some sort of typo has crept in.

The kernel and kernel-headers packages update normally, however kernel-tools and kernel-tools-libs have a conflict with the gnome-applets and gnome-flashback packages as shown below:

Problem 1: problem with installed package gnome-applets-3.50.0-2.fc39.x86_64 - package gnome-applets-3.50.0-2.fc39.x86_64 from @System requires libcpupower.so.0()(64bit), but none of the providers can be installed - package gnome-applets-3.50.0-2.fc39.x86_64 from fedora requires libcpupower.so.0()(64bit), but none of the providers can be installed - cannot install both kernel-tools-libs-6.6.2-200.fc39.x86_64 from @commandline and kernel-tools-libs-6.5.4-300.fc39.x86_64 from @System - cannot install both kernel-tools-libs-6.6.2-200.fc39.x86_64 from @commandline and kernel-tools-libs-6.5.4-300.fc39.x86_64 from fedora - cannot install the best update candidate for package kernel-tools-libs-6.5.4-300.fc39.x86_64 Problem 2: problem with installed package gnome-flashback-3.50.0-2.fc39.x86_64 - package gnome-flashback-3.50.0-2.fc39.x86_64 from @System requires gnome-applets(x86-64), but none of the providers can be installed - package gnome-flashback-3.50.0-2.fc39.x86_64 from fedora requires gnome-applets(x86-64), but none of the providers can be installed - package gnome-applets-3.50.0-2.fc39.x86_64 from @System requires libcpupower.so.0()(64bit), but none of the providers can be installed - package gnome-applets-3.50.0-2.fc39.x86_64 from fedora requires libcpupower.so.0()(64bit), but none of the providers can be installed - cannot install both kernel-tools-libs-6.6.2-200.fc39.x86_64 from @commandline and kernel-tools-libs-6.5.4-300.fc39.x86_64 from @System - cannot install both kernel-tools-libs-6.6.2-200.fc39.x86_64 from @commandline and kernel-tools-libs-6.5.4-300.fc39.x86_64 from fedora - package kernel-tools-6.6.2-200.fc39.x86_64 from @commandline requires libcpupower.so.1()(64bit), but none of the providers can be installed - package kernel-tools-6.6.2-200.fc39.x86_64 from @commandline requires kernel-tools-libs = 6.6.2-200.fc39, but none of the providers can be installed - cannot install the best update candidate for package kernel-tools-6.5.4-300.fc39.x86_64

I have also downgraded to octave-8.3.0 with the same qt5-qtbase packages and it works perfectly well.

Yes, it should be a feature update rather than a bug fix as octave itself did not cause the original problem.

FWIW I have this installed together with the qt5-qtbase-5.15.11-6 package updates and the GUI octave window opens normally.

Deleted and reinstalled kernel-6.6.1-300 after updating to this new dracut package, initramfs rebuilt OK automatically and now microcode shows as correctly loaded in dmesg:

$ dmesg | grep microcode [ 0.000000] microcode: updated early: 0xd6 -> 0xfa, date = 2023-02-27 [ 1.022577] microcode: Microcode Update Driver: v2.2.

This seems to be working as expected now after the kernel-6.6 microcode config changes.

Reinstalled the -11 package from Koji, seems to be OK with cqrprop working as expected.