Thanks @aitvaras for the hint. Turns out it was indeed related to the dreaded libsolv issue. Downgrading to 0.7.15 also fixed the issue for me, so I closed the bug.
Is there a ticket for the libsolv + rpm-ostree override ... issue already?
Well there is this libsolv-0.7.17-1.fc33 failure tracker Ā· Issue #2548 Ā· coreos/rpm-ostree Ā· GitHub
This one found on the libsolv failure tracker seems relevant: https://bugzilla.redhat.com/show_bug.cgi?id=1925717
This is now solved (for me):
- upgrade to rpm-ostree-2021.1-4.fc33 and reboot to make active.
- execute override-command as originally documented, and now the overrides should again apply.
See https://bodhi.fedoraproject.org/updates/FEDORA-2021-9091468793 for solution details, and the bug in bugzilla documents how to apply the upgrade if custom rollback is necessary.
Can confirm: Works for me now, as well.
How can I check if PipeWire is included in current nightly images? (I mean, before installing)
Iāve read the contribute page, but thereās no link to the repository where the code to build images is stored.
Iām not on a Silverblue instance right now, but try rpm -qa | grep pipewire.
Also, as of Fedora 35 (IIRC) it is the default. So pactl info would reflect that. (See my initial post for more details on this.)
@cobratbq thanks, but your reply doesnāt answer my question, as I wanted to check if pipewire was present in Fedora rawhide in February before installing.
I think pipewire is the default since Fedora 34. I donāt have pactl installed, so:
$ ps aux | grep pipewire
fede 1882 0.0 0.2 346524 18612 ? S<sl 14:47 0:00 /usr/bin/pipewire
fede 1883 0.0 0.2 261824 17936 ? S<sl 14:47 0:00 /usr/bin/pipewire-pulse
fede 1892 0.0 0.0 252856 7964 ? S<l 14:47 0:00 /usr/bin/pipewire-media-session
fede 29883 0.0 0.0 221544 852 pts/1 R+ 17:13 0:00 grep --color=auto pipewire
$ cat /etc/os-release | grep VERSION
VERSION="34.20210831.0 (Silverblue)"
True. You would need to look up what the contents are for a particular Silverblue image. Youāre right. Iām off-by-one on the Fedora version. 
I guess if you donāt have pactl, thatās already a sign that the system is less reliant on Pulse Audio. Any Pulse Audio management interace (both cli and gui) can work, really. As long as it displays information on the Pulse Audio server/version.
Indeed, check the running processes: pipewire-pulse is the substitute interface for applications that expect Pulse Audio. In addition, you can check how much of pulse audio processes are running. Iād expect there to be none, or very few. (Again, disclaimer that I cannot check on a running system right now.)
Did you look at pw-cli? the pipewire command line interface.
Pipewire is definitely default, no Pulse in sight (other than the Pipewire interface).
[matthew@fedora ~]$ ps aux | grep pulse
matthew 1796 0.0 0.1 258192 19024 ? S<sl 21:19 0:00 /usr/bin/pipewire-pulse
matthew 35181 0.0 0.0 221528 856 pts/0 S+ 22:17 0:00 grep --color=auto pulse
[matthew@fedora ~]$ ps aux | grep pipewire
matthew 1795 0.0 0.1 346212 17620 ? S<sl 21:19 0:01 /usr/bin/pipewire
matthew 1796 0.0 0.1 258192 19024 ? S<sl 21:19 0:00 /usr/bin/pipewire-pulse
matthew 1810 0.0 0.0 252676 11932 ? S<l 21:19 0:00 /usr/bin/pipewire-media-session
matthew 35187 0.0 0.0 221528 788 pts/0 S+ 22:17 0:00 grep --color=auto pipewire
These commands also gave a ton of information:
pw-cli info all
pw-cli dump all
I really like how GNOME is at the forefront of Wayland and Pipewire. Also Iāve read where GStreamer is in many ways a better mulimedia framework than the popular FFmpeg (easier for developers, many more libraries, capable of more advanced workflows).
I did wish they hadnāt hitched their wagon to Webkitā¦ not sure about that decision, but in all honesty when I tried version 41 in GNOME OS it was way better than it was on Fedora. Fast and actually rendered sites properly.