What @mandree said: while the update is functional, it doesn’t resolve the SELinux issues. If I update to smartmontools-selinux-7.2-9.fc33, and then disable my custom smartmon-bz1990463 SELinux module, the same avc denials return.

This update appears to correct BZ#1880948:

$ restorecon -FR -v /run/chrony*
$ ls -lsaZ /run/chrony*
/run/chrony:
total 4
0 drwxr-x---.  2 chrony chrony system_u:object_r:chronyd_var_run_t:s0   80 May  2 13:49 ./
0 drwxr-xr-x. 59 root   root   system_u:object_r:var_run_t:s0         1720 May  2 02:01 ../
4 -rw-r--r--.  1 root   root   system_u:object_r:chronyd_var_run_t:s0    5 May  2 01:49 chronyd.pid
0 srwxr-xr-x.  1 chrony chrony system_u:object_r:chronyd_var_run_t:s0    0 May  2 01:49 chronyd.sock=

/run/chrony-dhcp:
total 4
0 drwxr-xr-x.  2 root root system_u:object_r:chronyd_var_run_t:s0   60 May  2 13:49 ./
0 drwxr-xr-x. 59 root root system_u:object_r:var_run_t:s0         1720 May  2 02:01 ../
4 -rw-r--r--.  1 root root system_u:object_r:chronyd_var_run_t:s0   26 May  2 13:49 enp7s0.sources

"Yes, this behavior is intentional; it isn't a bug" would have sufficed.

With 1.20.3-1, I'm seeing a 1-pixel border on panels that I can't remove.

This is very, very annoying if you have panels set to be 0% opaque (this is, 100% transparent), because the 1-pixel border ruins the "icons just floating against the background" effect.

This is new behavior with 1.20.3-1; I didn't see this issue with 1.20.2-1. Is it intentional?

I opened BZ#1572944 (4.16.4-200.fc27.x86_64 hangs during boot on AMD system).

On my system (AMD A10-7800 Radeon R7, ASUSTeK A88XM-E), this kernel hangs during the boot process. It makes it this far:

[    2.326086] usb 3-2: New USB device found, idVendor=046d, idProduct=c24c
[    2.328038] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    2.328984] usb 3-2: Product: G400s Optical Gaming Mouse
[    2.329915] usb 3-2: Manufacturer: Logitech
[    2.338356] input: Logitech G400s Optical Gaming Mouse as /devices/pci0000:00/0000:00:12.0/usb3/3-2/3-2:1.0/0003:046D:C24C.0004/input/input4
[    2.340400] hid-generic 0003:046D:C24C.0004: input,hidraw3: USB HID v1.10 Mouse [Logitech G400s Optical Gaming Mouse] on usb-0000:00:12.0-2/input0
[    2.345363] hid-generic 0003:046D:C24C.0005: hiddev98,hidraw4: USB HID v1.10 Device [Logitech G400s Optical Gaming Mouse] on usb-0000:00:12.0-2/input1

According to the dmesg output from the previous kernel, 4.16.3-200.fc27.x86_64, the next lines should be:

[    2.386486] [drm] radeon kernel modesetting enabled.
[    2.387492] checking generic (e0000000 300000) vs hw (e0000000 10000000)
[    2.387493] fb: switching to radeondrmfb from EFI VGA
[    2.388569] Console: switching to colour dummy device 80x25
[    2.412982] [drm] initializing kernel modesetting (KAVERI 0x1002:0x130F 0x1043:0x85CB 0x00).
[    2.413020] [drm] doorbell mmio base: 0xF0000000
[    2.413023] [drm] doorbell mmio size: 8388608
[    2.413081] ATOM BIOS: 113
[    2.413128] radeon 0000:00:01.0: VRAM: 1024M 0x0000000000000000 - 0x000000003FFFFFFF (1024M used)
[    2.413132] radeon 0000:00:01.0: GTT: 2048M 0x0000000040000000 - 0x00000000BFFFFFFF
[    2.413137] [drm] Detected VRAM RAM=1024M, BAR=256M

…but 4.16.4-200.fc27.x86_64 never gets there.

If I type on the keyboard, letters appear on the screen, and I can Ctrl-Alt-Del to reboot. But otherwise, the kernel is hung.

It looks like there's a fairly bad regression for at least some percentage of AMD systems?

8.30.0-3 corrects BZ#1505853 (rsyslog-8.30.0-1.fc26.x86_64 breaks $IMJournalStateFile) for me.

This fixes the directory perms on /var/run/nagios (0775 instead of 0755).