OK, I see you have some cmake target files in -devel and some in -static. I'm no cmake guy, but... -devel should be enough to develop against SDL2, i.e. against all targets, should't it?

We see builds of darktable failing with this now. SDL2 2.0.18-3 seems to contain db732fc Add missing SDL2Targets files to devel subpackage (even though it's not mentioned in clog). Is that maybe not complete? Do we have to buildrequire more than cmake(SDL2) now? gives CMake Error at /usr/lib64/cmake/SDL2/SDL2Config.cmake:42 (get_target_property): get_target_property() called with non-existent target "SDL2::SDL2main".

The same darktable spec used to work last week.



Having kernel{,-core,-devel,-modules,-modules-extra} at .4 but kernel-{headers,tools,tools-libs} at .3 looks a bit unsusal and might even throw off some third party modules or tools.

So, technically this is a regression reintroducing bug #1851668

This pulls in new dependencies (flatpak, ostree-libs) which it did have before (see below). Also, it cannot be erased due to the dependency. Why are flatpak and ostree forced upon us?

dnf erase xdg-desktop-portal Error: Problem: The operation would result in removing the following protected packages: gnome-shell

Installing dependencies: flatpak-selinux noarch 1.10.1-1.fc33 updates 23 k flatpak-session-helper x86_64 1.10.1-1.fc33 updates 79 k ostree-libs x86_64 2020.8-1.fc33 updates 427 k Installing weak dependencies: flatpak x86_64 1.10.1-1.fc33 updates 1.7 M p11-kit-server x86_64 0.23.22-2.fc33 updates 199 k xdg-desktop-portal-wlr x86_64 0.1.0-2.fc33 fedora 34 k

The real issue is that ghostscript does not require the exact version of jbig2dec that it depends on. So, ghostscript needs a rebuild and an update for the requires.


Unfortunately, this update has been pushed to stable for F29 before even submitting an update for F30 at all. It breaks system-upgrade from F29 to F30 completely!

Since the previous version is not in updates any more users are forced to downgrade all the way down to the F29 base version, which is no good version for the dist-upgrade.



Also, this solves for me (ACPI BAT/CHR events on older Samsung Ultrabooks).


If you are bitten by the dracut bug head over to the dracut update

Changing karma to +1 +1 here.

BZ#1676357 dracut-install[7836]: segfault at 0 ip 0000562144297444 sp 00007ffdb5ad3588 error 4 in dracut-install

While the kernel installs and boots there is a reproducible segfault for dracut-install ( with the current dracut. It s not clear yet whether this a dracut issue or a kernel 5.0 issue. So +1 one for the working update, -1 for the segfault during dnf update.

Maybe it's worth amending this with "Fix CVE-2019-8912 (rhbz 1678685 1678686)" (bb99dec73, current tip of f29 in dist-git)?

(addition to the previous comment: 4.19.3 worked as well, the 4.19. kernel before that did not)


Fedora 4.19 kernels before 4.19.5 and after show an acpi crash for me on an old HP/compaq 6715b laptop with an AMD Turion. Same crash with 4.19.8, whereas 4.19.5 did work. Low and behold: the koji build ("atomacpi") works, the kernel boots as usual. acpitool -c says:

CPU type : AMD Turion(tm) 64 X2 Mobile Technology TL-60 Min/Max frequency : 800/2000 MHz Current frequency : 800 MHz Frequency governor : ondemand Freq. scaling driver : powernow-k8 Cache size : 512 KB Bogomips : 3989.80 Bogomips : 3989.80 Function Show_CPU_Info : could not read directory /proc/acpi/processor/ Make sure your kernel has ACPI processor support enabled.

BZ#1628943 ghostscript 9.24 breaks import of eps with scribus
BZ#1628943 ghostscript 9.24 breaks import of eps with scribus
User Icon mjg commented & provided feedback on pygame-1.9.4-3.fc29 4 years ago

This package has been pushed to F28 but not F29. The dependencies are messed up but I'm not sure whether the problem is in -3 or in the earlier versions. Rebuilding my package impressive which depends on python2-pygame (unversioned) and reinstalling helped. Maybe it is as simple as a missing explicit Provides: python2-pygame for the subpackage.

In any case, having this in F28 forces maintainers of depending packages to bump their F28 versions for a fix - and not pushing it to F29 is not quite what we are supposed to do.