Description of problem: Cannot launch gnome-control-center due to undefined symbol error. Version-Release number of selected component (if applicable): gnome-control-center-41~beta-3.fc35.x86_64 webkit2gtk3-2.33.3-3.fc35.x86_64 How reproducible: Every time Steps to Reproduce: 1. Log into GNOME on Fedora 35 with the latest updates (and testing updates) 2. Open a terminal 3. Run `gnome-control-center` Actual results: gnome-control-center: symbol lookup error: /lib64/libwebkit2gtk-4.0.so.37: undefined symbol: gst_element_request_pad_simple Expected results: I should be able to access GNOME settings. Additional info: The system journal appears to show this same error for numerous other GNOME components including gnome-online-accounts and gnome-calendar.
Proposed as a Blocker for 35-beta by Fedora user sgallagh using the blocker tracking app because: "No part of any release-blocking desktop's panel (or equivalent) configuration may crash on startup or be entirely non-functional."
I'm not sure if it's relevant, but I upgraded this system from Fedora 34 using `dnf offline-upgrade`.
(In reply to Stephen Gallagher from comment #0) > gnome-control-center: symbol lookup error: /lib64/libwebkit2gtk-4.0.so.37: > undefined symbol: gst_element_request_pad_simple This symbol is new in GStreamer 1.20. It seems WebKitGTK was built against a newer version of GStreamer than is actually being used at runtime. That's bad. Please run: $ rpm -qi gstreamer1 | grep -C1 Version $ rpm -qi webkit2gtk3 | grep -C1 Version Looking at the buildroot for webkit2gtk3-2.33.3-3.fc35 in https://kojipkgs.fedoraproject.org//packages/webkit2gtk3/2.33.3/3.fc35/data/logs/x86_64/root.log, I see: DEBUG util.py:446: gstreamer1-devel x86_64 1.19.1-2.fc35 build 507 k Are you running against a version of GStreamer that is older than this?
Name : gstreamer1 Version : 1.19.1 Release : 2.1.18.4.fc34 Name : webkit2gtk3 Version : 2.33.3 Release : 3.fc35 It appears that gstreamer wasn't updated when I did the upgrade (because it has a higher ENVR, I think).
And, indeed if I "downgrade" gstreamer1, I have access to the settings without the error. So we probably need to figure out why that's not being done on upgrade, since I thought `dnf offline-upgrade` was supposed to do a distro-sync.
Well it didn't get upgraded because 1.19.1-2.1.18.4.fc34 is obviously greater than 1.19.1-2.fc35, and you did a normal upgrade instead of a distro-sync. Once upon a time, we would have said "the upgrade path is broken" and treated this as a bug, but nowadays you're expected to use 'dnf system-upgrade' if you want to upgrade via dnf. So I'm going to close this as NOTABUG. (In reply to Stephen Gallagher from comment #5) > So we probably need to figure out why that's not being done on upgrade, > since I thought `dnf offline-upgrade` was supposed to do a distro-sync. Nope, 'dnf offline-upgrade' is for normal updates. Hopefully a distro-sync will get you back to a consistent state.
BTW the problem is 1.19.1-2.1.18.4.fc34 is *really* 1.18.4. It somehow got upgraded in F34 by mistake, then we downgraded it again and just hoped nothing had started depending on 1.19.1 yet. That actually worked fine for F34, you just don't want the package installed on your F35 box.