Comments

126 Comments

Several of the builds are missing the epel8-testing-candidate tag. They need to be tagged with that before the push can proceed.

karma

Koschei still reports broken dependencies with the proj build:

https://koschei.fedoraproject.org/package/kdelibs?collection=f32

- package qt-mobility-location-1.2.2-0.37.20140317git169da60c.fc32.x86_64 requires libproj.so.15()(64bit), but none of the providers can be installed
- conflicting requests
- nothing provides proj-datumgrid = 1.8-6.3.1.2 needed by proj-6.3.1-2.fc32.x86_64

I am sending this one to stable now, it is definitely an improvement over the status quo. I will be pushing a fix for #416037 to testing soon. If there are any fixes needed for coordinate precision, please point me to those so that I can apply those, too.

I am sending this one to stable now, it is definitely an improvement over the status quo. I will be pushing a fix for #416037 to testing soon. If there are any fixes needed for coordinate precision, please point me to those so that I can apply those, too.

That's because the fix is only in the release/19.12 branch and was not merged to master yet.

however the new value does not seem to affect the number of decimal digits printed. This is by sure an upstream issue and I will open a report there.

I still don't see an upstream report for that…

I reopened your downstream report https://bugzilla.redhat.com/show_bug.cgi?id=1778000 but I cannot promise anything at this time.

Do you have a backtrace for the crash? I don't think the warnings you see on the console are related.

Isn't it time to push this to stable?

It looks like kf5-kio broke binary compatibility for ioslaves, Krusader's kio_krarc no longer loads here.

Oh and, have you tried logging out and back in after applying the update? (Or even rebooting the computer entirely?) Otherwise, you can end up with a mix of different library versions in memory, which can be the cause of your crash. Logging out and back in should fix it (because it will force your computer to reload the libraries from disk).

What kind of files? (At least: what file type/extension?) Opening files from Dolphin works fine here.

Well, that's a DNF bug: it still considers the old liberation-fonts package (2.00.5-1) for Obsoletes and complains that it cannot use it. Obsoletes in old versions of a package are supposed to be ignored (so that removing Obsoletes works reliably), this used to work. Something must have regressed in DNF. (Maybe this was changed due to Modularity?) Please file a bug against DNF.

But for now, this should not prevent you from upgrading. (It will just skip the packages it cannot handle.) So it is better than before where DNF refused to install liberation-narrow-fonts entirely.

Works fine: I can install liberation-narrow-fonts now (no more bogus Obsoletes), thanks.

BZ#1707712 liberation-fonts.noarch should not Provides or Obsoletes liberation-narrow fonts

Works fine on my notebook.

karma

Unversioned Obsoletes: compton is not allowed, you need to specify a reasonable maximum version to obsolete, in case compton becomes a thing again (either by merging compton-ng or by independent development).

You also need to provide evidence that the Obsoletes is agreed with the current maintainer of the compton package. This goes even for Rawhide! Either you both agree to retire the compton package in favor of compton-ng, or compton-ng cannot unilaterally Obsoletes: compton. Without consensus, even a versioned Obsoletes would still not be acceptable.

For this update, you also need to provide evidence that forcefully migrating users of the stable Fedora 30 release complies with the update policies for stable releases. Otherwise, even a versioned Obsoletes, and even if agreed for Rawhide, would still not be acceptable in this update.

See:

BZ#1738293 Review Request: compton-ng - Compositor for X11, active fork

It turns out that the UEFI issue is not caused by the update. UEFI works in the VM with a fresh disk image and not with a reused one. It is unclear whether it works on real hardware. But the update does not make this any better or worse, so let us just push the security update now and look into UEFI later.

It turns out that the UEFI issue is not caused by the update. UEFI works in the VM with a fresh disk image and not with a reused one. It is unclear whether it works on real hardware. But the update does not make this any better or worse, so let us just push the security update now and look into UEFI later.