Thanks!

Ah, I see. Thanks for clearing this up! Could you also file all the details in bugzilla, please, so that @limb who dealt with the first crash can see this? You could perhaps open a new ticket, or maybe just re-open https://bugzilla.redhat.com/show_bug.cgi?id=2169837 and add the details there.

As I understand it, the update to transmission 4.0.0 caused transmission-daemon to start crashing and transmission-4.0.0-2.fc37 didn't fix it completely. transmission-4.0.0-2.fc37 was however pushed to stable updates so it's already broken now for everybody.

This update (4.0.0-3.fc37) didn't fix the crash, but it wasn't supposed to either - it contained an entirely unrelated change. When you compare it to the 4.0.0-2.fc37 update that's in stable updates, this update doesn't make the situation for the crash worse - it's the same. In other words, you could say that this update doesn't regress compared to 4.0.0-2.fc37.

This is an important distinction because the feedback and karma in Bodhi is supposed to be for regression testing.

@aptupdate Is that a regression compared to transmission-4.0.0-2.fc37 build from FEDORA-2023-e83dc0e6cb ? There shouldn't be any changes in how the daemon is built between the 4.0.0-2 and 4.0.0-3 builds.

Awesome, thanks for testing!

Works fine in quick testing (and the new build makes it work in a wayland session as well)

Note that this is a continuation of FEDORA-2022-5b019245ff that got unpushed because of broken dependencies. This update here now adds a libavif0.10 compat package to avoid this issue (the compat package is for third party packages; everything in Fedora is rebuilt), and hopefully gets the update over the finish line.

I did a libavif0.10 compat package to help get this one over the finish line and submitted it all again as FEDORA-2022-c8eab6e6f1

I went ahead and did a libavif0.10 compat package to fix the issue with the soname/ABI changing and breaking other packages.

ngompa also suggested that we enable rav1e support for EPEL 9, so I went ahead and did that too while at this.

Haven't noticed any regressions.

Haven't noticed any issues here.

I couldn't spot any regressions in quick testing. I don't have Enterprise wifi here but kparal already covered that part.

Can you also rebuild dependent packages that use the gtk4 ABI?

Haven't noticed any regressions here.

@burakdede Maybe you can mention it upstream at https://gitlab.gnome.org/GNOME/gdk-pixbuf ? This fix here (backport of https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/merge_requests/143) definitely helps, but is apparently not enough to fix all cases.

I missed one rebuild, should have had mutter-43.0-3.fc38 here as well.

Untagging as a number of openQA tests appear to have started failing with this build.

Untagging as a number of openQA tests appear to have started failing with this build.

Unpushing as a number of openQA tests appear to have started failing with this build.