The missing Provides are indeed fixed, nothing tries to drag in Java 9 anymore. Also no regressions noted.

(By the way, I don't think enabling autopush is a good idea here, because this update depends on the NSS update.)

I pulled this in as a dependency of the latest OpenJDK update. Everything on the system seems working as before, I don't see any regressions.

I can confirm that this fixes https://bugreports.qt.io/browse/QTBUG-68939 in both Kompare and KDevelop.

Everything else keeps working as before.

Less dependency bloat is always a good thing, ship it!

FYI, Qt 5 is included in RHEL 7, and it was recently upgraded there from 5.6 LTS to 5.9 LTS, is that still too old?

The issue I am having might actually not be caused by this update after all. I have also seen this come up on a F27 remix around the same time (~a week ago), and no grub2 update reached stable there at that time.

See: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/F6QQ4EGTOBVDJ7HHUO7ZW3GEHGA7XQT5/

@hreindl:

qt5-qtwebengine-freeworld is not part of Fedora and so when anything needs a version-locked depedency than qt5-qtwebengine-freeworld itself - there is no justification that a non-fedora package triggers a negative karma for a fedora package!

Please read my description of the issue. qt5-qtwebengine-freeworld correctly has a version-locked dependency on qt5-qtwebengine and qt5-qtbase, which is why qt5-qtbase is being held back in the first place. It is qt5-qtwebchannel that is missing the version-locked dependency on qt5-qtbase, which lets dnf upgrade qt5-qtwebchannel while holding back qt5-qtbase. This is an error in qt5-qtwebchannel packaging and must be fixed in qt5-qtwebchannel packaging.

FYI, this has to wait for the F27 update to be pushed to stable first, which in turn has to wait for the -freeworld package to be ready. Please be patient.

FYI, the reason I am not pushing this to stable yet is that the -freeworld package is still being built, there are issues with the armv7hl build over there.

I really tried to get mesa fixed, but since they categorically refuse to apply the existing patches, Qt upstream gave up waiting and ended up adding this workaround. It makes me really sad, but with Nouveau upstream and downstream and FESCo conspiring to continue shipping a broken driver, there is no other option.

3.1.8 adds the following fixes:

• (bug) Netinstall would crash if the returned netinstall-groups data was empty.
• (regression vs. 3.0.x) UI glitch: netinstall would display the description as the name (ignoring the actual name) and show an empty description.
• (regression) GeoIP data had already been read, don't read it twice.
• Use more support code from KPMCore, instead of doing it ourselves.

3.1.8 adds the following fixes: * (bug) Netinstall would crash if the returned netinstall-groups data was empty. * (regression vs. 3.0.x) UI glitch: netinstall would display the description as the name (ignoring the actual name) and show an empty description. * (regression) GeoIP data had already been read, don't read it twice. * Use more support code from KPMCore, instead of doing it ourselves.

3.1.7 fixes the following regressions:

• Netinstall was no longer compatible with the packages module (regression in 3.1.4), which prevented any users of netinstall from installing packages from online repositories.
• The bootloader installation for EFI systems used the wrong name for the bootx64.efi (or bootia32.efi) files (regression in 3.1.1). The file was installed as grubx64.efi (or grubia32.efi). Some firmwares (in particular, the one in VirtualBox) are very picky about the name of that file and expect it to be bootx64.efi (or bootia32.efi), the installed system should now boot without tweaking on those systems again.

3.1.7 fixes the following regressions:

• Netinstall was no longer compatible with the packages module (regression in 3.1.4), which prevented any users of netinstall from installing packages from online repositories.
• The bootloader installation for EFI systems used the wrong name for the bootx64.efi (or bootia32.efi) files (regression in 3.1.1). The file was installed as grubx64.efi (or grubia32.efi). Some firmwares (in particular, the one in VirtualBox) are very picky about the name of that file and expect it to be bootx64.efi (or bootia32.efi), the installed system should now boot without tweaking on those systems again.