This broke booting with FIPS. Just saying that this regression has been known for two months..

Over the years I've seen dozens of FIPS boot failures. Would it be possible to include this into the gating tests?

Sorry, false alarm - this update actually fixes this long-standing severity parsing bug:

This caused a regression with changelog severity parsing [1], but two days over a weekend was not enough time to catch this. I'll report to bugzilla instead.



Somehow this got stuck i "pending", even though both gating tests and user feedback said :+1. I tried "publish to testing" again.

We just caught this new regression in Cockpit's CI:

audit: type=1400 audit(1623381106.279:360): avc: denied { getattr } for pid=1784 comm="mdadm" path="/dev/dma_heap" dev="devtmpfs" ino=127 scontext=system_u:system_r:mdadm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dma_device_dir_t:s0 tclass=dir permissive=0

Given how new SELinux updates can potentially break everything, can you please let new versions simmer in updates-testing for at least two days or so? Updating within less than 24 hours is just not enough time to spot regressions.

Still doesn't work. Upgrading from Fedora 34 picks up the higher version number:

 conmon                    x86_64 fedora  53 k
                           x86_64 1.0.0-11.1.git8de0287.fc35       fedora 9.0 M
 containers-common         noarch 4:1-19.fc35                      fedora  60 k
 crun                      x86_64 0.20.3-0.12.git8d6a8b5.fc35      fedora 173 k

Why did that lower the version number? The previous release was 0.20.3, this is now 0.20.1. dnf won't downgrade by default. Can you please fix the version number?


Works out of the box under wayland, even in toolbox. Nice one, thanks Major!

BZ#1961783 Review Request: rofimoji - A character picker for rofi

Nack, this breaks kdump. After an opps, the crash dump is not generated, and kdump.service fails:

‚óŹ kdump.service - Crash recovery kernel arming
     Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset: disabled)
     Active: failed (Result: exit-code) since Fri 2021-05-21 04:48:50 UTC; 23s ago
    Process: 582 ExecStart=/usr/bin/kdumpctl start (code=exited, status=1/FAILURE)
   Main PID: 582 (code=exited, status=1/FAILURE)
        CPU: 185ms

May 21 04:48:49 localhost systemd[1]: Starting Crash recovery kernel arming...
May 21 04:48:50 localhost kdumpctl[896]: /usr/lib/dracut/ line 237: get_maj_min_cache_file: parameter null or not set
May 21 04:48:50 localhost kdumpctl[895]: /usr/lib/dracut/ line 241: get_maj_min_cache_file: parameter null or not set
May 21 04:48:50 localhost kdumpctl[902]: /usr/bin/kdumpctl: line 504: perror: command not found
May 21 04:48:50 localhost kdumpctl[598]: kdump: Starting kdump: [FAILED]
May 21 04:48:50 localhost systemd[1]: kdump.service: Main process exited, code=exited, status=1/FAILURE
May 21 04:48:50 localhost systemd[1]: kdump.service: Failed with result 'exit-code'.
May 21 04:48:50 localhost systemd[1]: Failed to start Crash recovery kernel arming.

Installs, upgrades, and works fine. VM deletion crash is fixed.

Installs, upgrades, and works fine. Deletion crash is fixed.


Install and upgrade from 242-1 went fine. I went through all the pages, and they behave as expected.

I just pushed a new build in FEDORA-2021-811491ace1 that fixes the file conflict with selinux-policy-doc.


First I upgraded to Fedora 34 (as the coreos/testing branch is still F33):

ostree rebase fedora:fedora/x86_64/coreos/next

Then I confirmed the bug with current F34 dpkg:

rpm-ostree install dpkg
# [..]
# error: Running %post for dpkg: bwrap(/bin/sh): Child process killed by signal 1; run `journalctl -t 'rpm-ostree('` for more information

Test the proposed update:

rpm-ostree install
# succeeded!
dpkg --help


BZ#1817258 Can't install dpkg on Silverblue / rpm-ostree

previous CI run failure flaked TestMachinesNICs.testNICAdd. Retrying for comparison.

I downloaded from the current 241-1.fc34 to 242.1-1.fc34. The upgrade worked fine, the Page works, and there is no visual difference (as intended).

Confirming that this package works well together with the new tmt in for running in toolbox with session qemu. Splendid, thank you!