Can confirm that it works without the glib2 update.
Some general gnome 49 issues I found:
- Backlight shortcuts seem to be broken
- Codec options are unreadable (sound > output > configuration), all options show "High fidelity playback..."
The difference between -2 and -1 is rsvg-pixbuf-loader was removed (because the new gdk-pixbuf2 will never use it). So downgrading only librsvg shouldn't be enough to affect anything. Is that really all you needed to get Breeze icons working again? You didn't have to downgrade gdk-pixbuf as well? I think you would need to downgrade both to see a difference.
SVG loading via gdk-pixbuf should be handled by Glycin now. If downgrading gdk-pixbuf was required to fix the problem, then we can report a bug to gdk-pixbuf. If downgrading librsvg alone was sufficient to fix the problem, then I am bamboozled; that really doesn't make sense.
Some general gnome 49 issues I found: - Backlight shortcuts seem to be broken
Looks like there were related changes in gnome-settings-daemon, so that must be the culprit. A bug report on GNOME GitLab would be appreciated.
Codec options are unreadable (sound > output > configuration), all options show "High fidelity playback..."
Odd. My first suspect would be Pipewire, but we didn't update Pipewire here. My next best guess for where to report a bug is gnome-control-center. And I see there are related changes there, so again: bug report on GNOME GitLab would be appreciated.
Problem 2: package glycin-loaders-2.0~rc-3.fc43.i686 from updates-testing requires libheif.so.1, but none of the providers can be installed
- package libheif-1.20.1-2.fc43.i686 from fedora requires libopenh264.so.8, but none of the providers can be installed
- package libheif-1.20.2-3.fc43.i686 from updates-testing requires libopenh264.so.8, but none of the providers can be installed
- package glycin-libs-2.0~rc-3.fc43.i686 from updates-testing requires glycin-loaders(x86-32) = 2.0~rc-3.fc43, but none of the providers can be installed
- installed package openh264-2.6.0-2.fc43.x86_64 conflicts with openh264 provided by noopenh264-2.6.0-2.fc43.i686 from fedora
- installed package openh264-2.6.0-2.fc43.x86_64 obsoletes noopenh264 < 1:0 provided by noopenh264-2.6.0-2.fc43.i686 from fedora
- package gdk-pixbuf2-2.43.5-2.fc43.i686 from updates-testing requires libglycin-2.so.0, but none of the providers can be installed
- cannot install the best update candidate for package openh264-2.6.0-2.fc43.x86_64
- cannot install the best update candidate for package gdk-pixbuf2-2.43.3-7.fc43.i686
So when previously mozilla-openh264.x86_64 and openh264.x86_64, gdk-pixbuf2-2.43.3-7.fc43.i686, and gdk-pixbuf2-2.43.3-7.fc43.x86_64 are installed:
New gdk-pixbuf2-2.43.5-2.fc43.i686 requires new dependency libglycin-2.so.0 <- which tries to pull in glycin-loaders-2.0~rc-3.fc43.i686
So newly dependency glycin-loaders-2.0~rc-3.fc43.i686 requires libheif.i686, which tries to pull in libopenh264.so.8
But this fails because openh264-2.6.0-2.fc43.x86_64 obsoletes noopenh264 < 1:0 (epoch is here, and obsoletes happends regardless of arch), and even noopenh264.i686 explicitly conflicts with openh264 (again regardless of arch)
So dnf gives up...
In short, when previously mozilla-openh264.x86_64 and gdk-pixbuf2-2.43.3-7.fc43.x86_64 are installed, upgrade fails.
No, the issue is that libheif.i686 pulls in noopenh264.i686 (since no openh264 i686 build is available in the x86_64 repos), which conflicts with the already-installed openh264.x86_64.
A possible way around this would be to build libheif without openh264 support on i686.
I've merged the builds from FEDORA-2025-275ebcfc6a plus an additional libheif change that should fix the installability issue for the gdk-pixbuf2.i686 on x86_64 / multilib case.
This should be the Final Form of the megaupdate now, bar any newly-discovered serious problems. Minor ones can be fixed in follow-ups. It's present in Beta-1.2 and Beta-1.3, please test and provide karma.
GNOME 49.0 will be released imminently, so not much point in adding new patches now. I bet that merge request will land prior to release. If not, then yes I can add the patch if you remind me.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'waiting'.
This update has been submitted for testing by bodhi.
This update's test gating status has been changed to 'failed'.
Installed with
koji-tool install --tagged f43-build-side-118214 --only-existing --yesand seems to work pretty wellcatanzaro edited this update.
New build(s):
Removed build(s):
Karma has been reset.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'passed'.
adamwill edited this update.
adamwill edited this update.
catanzaro edited this update.
New build(s):
Removed build(s):
Karma has been reset.
catanzaro edited this update.
New build(s):
Removed build(s):
Karma has been reset.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'failed'.
Huh, pretty crazy crash we're getting now, I guess caused by new gjs. I've uploaded the backtrace here.
These are the gnome-shell messages we get in the journal, for context:
This update has been pushed to testing.
Bodhi is disabling automatic push to stable due to negative karma. The maintainer may push manually if they determine that the issue is not severe.
Aha, I think it's glib2, not gjs. In Rawhide, it's the glib2 update that's failing.
Yeah downgrading glib2 (to glib2-2.85.4-1.fc43) makes my VM boot to gdm again
The glib2 update broke my Cinnamon desktop. Rest of the packages seem to work fine.
I opened https://gitlab.gnome.org/GNOME/glib/-/issues/3776 and https://bugzilla.redhat.com/show_bug.cgi?id=2393625 without much detail.
catanzaro edited this update.
Removed build(s):
Karma has been reset.
This update has been submitted for testing by catanzaro.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'passed'.
works ( w/o the glib2 update)
churchyard edited this update.
Can confirm that it works without the glib2 update.
Some general gnome 49 issues I found: - Backlight shortcuts seem to be broken - Codec options are unreadable (sound > output > configuration), all options show "High fidelity playback..."
I tested quickly and it doesn't look like the Help issue we're seeing in Rawhide - https://bugzilla.redhat.com/show_bug.cgi?id=2393694 - affects this update. So that's good news.
With librsvg2-2.61.0-2.fc43 Breeze icons not used in GTK apps in KDE, no problem with librsvg2-2.61.0-1.fc43
@nucleo does it work if you install glycin-thumbnailer ?
hmm, no, probably wouldn't...
This update has been pushed to testing.
This update can be pushed to stable now if the maintainer wishes
The difference between -2 and -1 is rsvg-pixbuf-loader was removed (because the new gdk-pixbuf2 will never use it). So downgrading only librsvg shouldn't be enough to affect anything. Is that really all you needed to get Breeze icons working again? You didn't have to downgrade gdk-pixbuf as well? I think you would need to downgrade both to see a difference.
SVG loading via gdk-pixbuf should be handled by Glycin now. If downgrading gdk-pixbuf was required to fix the problem, then we can report a bug to gdk-pixbuf. If downgrading librsvg alone was sufficient to fix the problem, then I am bamboozled; that really doesn't make sense.
Looks like there were related changes in gnome-settings-daemon, so that must be the culprit. A bug report on GNOME GitLab would be appreciated.
Odd. My first suspect would be Pipewire, but we didn't update Pipewire here. My next best guess for where to report a bug is gnome-control-center. And I see there are related changes there, so again: bug report on GNOME GitLab would be appreciated.
I can't reproduce the brightness issue, the latest kernel update or a reboot probably fixed it. Will report if it happens again.
For the other problem I created an issue: https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues?show=eyJpaWQiOiIzNTU3IiwiZnVsbF9wYXRoIjoiR05PTUUvZ25vbWUtY29udHJvbC1jZW50ZXIiLCJpZCI6MjI3MTEwfQ%3D%3D
decathorpe edited this update.
New build(s):
Removed build(s):
Karma has been reset.
This update has been submitted for testing by decathorpe.
Added a new glycin build that should help with getting glycin-thumbnailer installed on upgrade.
I was able to reproduce the brightness issue. I needed to connect my laptop to an external display and close / open it.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8648
This update has been pushed to testing.
catanzaro edited this update.
catanzaro edited this update.
New build(s):
Removed build(s):
Karma has been reset.
This update has been submitted for testing by catanzaro.
This update has been pushed to testing.
Looks good to me when doing some exploratory testing of the desktop and most default apps.
This update can be pushed to stable now if the maintainer wishes
Did some general testing of the update in an existing installation and most of my workflows seem to work in 49.rc.
100% crash rate when trying quake3e in full screen mode (vulkan or opengl). It does also crash with VK_DRIVER_FILES set to mesa llvmpipe.
catanzaro edited this update.
New build(s):
Karma has been reset.
This update has been submitted for testing by catanzaro.
Since you have a stack trace, you can report the mutter crash here: https://gitlab.gnome.org/GNOME/mutter/issues
So when previously mozilla-openh264.x86_64 and openh264.x86_64, gdk-pixbuf2-2.43.3-7.fc43.i686, and gdk-pixbuf2-2.43.3-7.fc43.x86_64 are installed:
In short, when previously mozilla-openh264.x86_64 and gdk-pixbuf2-2.43.3-7.fc43.x86_64 are installed, upgrade fails.
The previous comment was "when previously mozilla-openh264.x86_64 and gdk-pixbuf2-2.43.3-7.fc43.i686 are installed"
No, the issue is that libheif.i686 pulls in noopenh264.i686 (since no openh264 i686 build is available in the x86_64 repos), which conflicts with the already-installed openh264.x86_64.
A possible way around this would be to build libheif without openh264 support on i686.
quake3e crash https://gitlab.gnome.org/GNOME/mutter/-/issues/4310
adamwill edited this update.
Created https://src.fedoraproject.org/rpms/noopenh264/pull-request/1 to hopefully fix the i686 noopenh264 vs. openh264 conflicts.
catanzaro edited this update.
New build(s):
Karma has been reset.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'passed'.
decathorpe edited this update.
New build(s):
Karma has been reset.
I've merged the builds from FEDORA-2025-275ebcfc6a plus an additional libheif change that should fix the installability issue for the gdk-pixbuf2.i686 on x86_64 / multilib case.
This update has been pushed to testing.
The new libpeas1 build with backport from 1.38 breaks gitg builds. It's already broken by the same change in rawhide: https://koschei.fedoraproject.org/build/21370337 .
catanzaro edited this update.
New build(s):
Karma has been reset.
This update has been submitted for testing by catanzaro.
catanzaro edited this update.
New build(s):
Karma has been reset.
catanzaro edited this update.
New build(s):
Removed build(s):
Karma has been reset.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'passed'.
catanzaro edited this update.
New build(s):
Removed build(s):
Karma has been reset.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'passed'.
This should be the Final Form of the megaupdate now, bar any newly-discovered serious problems. Minor ones can be fixed in follow-ups. It's present in Beta-1.2 and Beta-1.3, please test and provide karma.
This update has been pushed to testing.
seems OK in openQA testing and in the first hour or so on my main system.
This update can be pushed to stable now if the maintainer wishes
Working fine here
This update has been submitted for stable by catanzaro.
There is an ongoing freeze; this will be pushed to stable after the freeze is over.
This update has obsoleted xed-3.8.4-1.fc43, and has inherited its bugs and notes.
catanzaro edited this update.
could we merge this https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4648 as a patch? this prevents the quake3e crash. I've verified this with a copr build: https://download.copr.fedorainfracloud.org/results/anotheruser/test/fedora-43-x86_64/09547790-mutter/
This update has been pushed to stable.
GNOME 49.0 will be released imminently, so not much point in adding new patches now. I bet that merge request will land prior to release. If not, then yes I can add the patch if you remind me.