Comments
kalev
You'll have to update python3-gexiv2 in the same transaction as libgexiv2 because python3-gexiv2 requires exact matching version of libgexiv2.
Can you verify that nautilus-44.2.1-1.fc38, https://bodhi.fedoraproject.org/updates/FEDORA-2023-ec6cec80b4 fixes this?
Upstream just released nautilus 44.2.1 which should fix this. I've kicked off builds for F38 and rawhide.
Sure, fine with me to backport the patch to 3.38.3. Do you want to do a PR for that?
I think I'd give upstream a bit of time first though and see if they can figure out the lagging and freezing issue first.
Confirmed that this fixes the provides generation for /app-installed flatpak builds.
Re-submitting to testing as the selinux issues should be fixed with selinux-policy-38.10-1.fc38 build from https://bodhi.fedoraproject.org/updates/FEDORA-2023-9e48ecef73
This update has been unpushed.
Hm, I guess that selinux-policy would need updating for new /etc/geoclue/conf.d/ config directory that geoclue 2.7.0 introduces. Do you want to help file a ticket against selinux-policy?
Note that this depends on https://bodhi.fedoraproject.org/updates/FEDORA-FLATPAK-2023-9a8818454b
Note that this depends on https://bodhi.fedoraproject.org/updates/FEDORA-FLATPAK-2023-9a8818454b
Seems to work fine in quick smoke testing.
Bummer :( Let's see what Akira figures out. I don't really know much about fontconfig.
Thanks - I was able to enable avif support in gthumb now.
Turns out it was caused by an nss mismatch in the flatpak runtime. Should be fixed by flatpak runtime update that's in https://bodhi.fedoraproject.org/updates/FEDORA-FLATPAK-2023-41da5c11ed
@dustymabe and I were discussing this on irc and we came up withflatpak-module install https://kojipkgs.fedoraproject.org//packages/thunderbird/stable/3720230208160301.1/images/oci-image-sha256:fefc42854ab0909f91ce33dca6ccaca0de78339e120da57b23e6e902723926ba.x86_64.tar.gz to downgrade to the previous version, if anyone else needs to get this worked around quickly.
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 https://bodhi.fedoraproject.org/updates/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.
Fixed FTBFS