I do not follow. The update https://bodhi.fedoraproject.org/updates/FEDORA-2026-86cdd6d41e did _revert_ the obsolete of the gdk-pixbuf2-modules-extra package, thus it should work differently.

Did you rather mean https://bodhi.fedoraproject.org/updates/FEDORA-2026-6c41884d0e ?

The former update is in the stable of rawhide now, the later was auto-stable-lized earlier.

Aha, no, I think I understand now. The gdk-pixbuf2-modules-extra had been retired and gdk-pixbuf2 pretended it provides it, but when I reverted the change retirement I also reverted the "provides", and because there is/was no real gdk-pixbuf2-modules-extra yet in rawhide it broke the dependencies.

I retired -modules-extra after the Obsoletes was added.  I've submitted an unretirement request in https://forge.fedoraproject.org/releng/tickets/issues/13287 but apparently there's been a problem with it.

Depending on the upstream [1], the retirement might probably by fine to do (after I revert the revert and add that patch, but I'm currently waiting for the upstream opinion on the change).

[1] https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/merge_requests/264

The upstream merge request 264 had been replaced with [2], which is part of the 2.44.6 release of the gdk-pixbuf. The update is currently building.

I re-applied the obsolete of the `gdk-pixbuf2-modules-extra`, because it should not be needed now. Please, retire it again. I'm sorry for the mess.

[2] https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/merge_requests/265

The rawhide/f45 update is [3]

[3] https://bodhi.fedoraproject.org/updates/FEDORA-2026-00cd338ef4

FEDORA-2026-b11f1d97f4 (gdk-pixbuf2-2.44.6-1.fc44) has been submitted as an update to Fedora 44.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-b11f1d97f4

Milan would like an FE for this. But we need to clarify what it's for.

The current stable package in F44 is gdk-pixbuf2-2.44.4-2.fc44 , which is from January. The gdk-pixbuf2-2.44.5-7.fc44 update never reached stable. The current stable gdk-pixbuf2-modules-extra is gdk-pixbuf2-modules-extra-2.44.0-2.fc44 ; that package was never retired on F44 AFAICS.

Based on that, my understanding is: F44 is actually currently in a good and consistent state, using the "legacy" XPM loader from gdk-pixbuf2-modules-extra . Pushing the update stable would result in gdk-pixbuf2 obsoleting gdk-pixbuf2-modules-extra (although it would still not be retired; I don't know if it's possible to retire a package during Final freeze, CCing Kevin) and the legacy XPM loader being moved into gdk-pixbuf2(? - I'm unclear about this, it's not clear whether the newer gdk-pixbuf2 contains a glycin XPM loader, the 'legacy' loader from -modules-extra, or both?)

On the whole I sort of feel like it might be safer to just stick with the status quo for F44, honestly, but if there's a good reason to pull the update in now, we could do it.

FEDORA-2026-b11f1d97f4 has been pushed to the Fedora 44 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-b11f1d97f4`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-b11f1d97f4

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

> On the whole I sort of feel like it might be safer to just stick with the status quo for F44

As the maintainer of gdk-pixbuf2-modules-extra, I agree.  The transition of XPM support to Glycin has been rocky, so this doesn't seem especially safe to push to F44 last-minute.

It's also worth emphasizing that if a FE is not granted, the change should not be pushed post-release.

I'll re-retire the F45 -modules-extra after some time has passed, in case there are additional problems.

Aha, okay, I thought 2.44.5 had made it into the f44. If not, then it's probably fine to not do the f44, though my understanding is that the gdk-pixbuf release is meant to go out together with the GNOME 50, which is f44. I can be wrong though.

According to the responses in the associated update the new version fixes the other apps.

Regarding the built-in XPM loader, I do not know the history behind it, but from what I see the gdk-pixbuf contains several built-in image parses, but Fedora does not enable them, thus it depends on the modules-extra to provide loaders for those formats. The made change in the 2.44.6 enables the built-in XPM loader only for the deprecated `gdk_pixbuf_new_from_xpm_data()`, thus that deprecated function works again. The XPM files are loaded through glycin.

My question is, do you really want to completely skip the f44 with this update? The mess the 2.44.5 caused was only due to the obsolete of the modules-extra, if I'm not mistaken. The aim of the upstream, as I understand it, is to rely on glycin, not on 3rd-party loaders.

I see the modules-extra offers only the XPM loader, as /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xpm.so , while the gdk-pixbuf2-2.44.6 update has that file too, thus the two packages clash on it, thus the obsolete of the modules-extra is actually a correct thing to do for two reasons (one is that the XPM file loader is provided by glycin 2.1.x and because of the clash on this libpixbufloader-xpm.so installed file).

It's also my understanding that upstream aims to switch to Glycin.  However, upstream also has a history of not being careful about breaking existing users, including most recently the problems with 2.44.5.  Historically -modules-extra was the result of one of these occurrences; I packaged it when the upstream maintainers removed a bunch of format support from the Fedora package that was still needed by other Fedora packages.

So, while I think the 2.44.6 update is probably correct, we've been burned by this transition several times and probably shouldn't risk it this late in F44.  I agree that 2.44.6 needs the Obsoletes to avoid file conflicts, which means we wouldn't be able to push .6 to F44 at all.

> which means we wouldn't be able to push .6 to F44 at all.

Works for me. We only need to figure out a way to not add any future updates of the gdk-pixbuf to the f44 too. While I know about it right now, I'll be stepping down as the gnome-sig packages "updater" soon, and even I'll return back after few months, I'll not know of "do not update in f44" rule myself for sure, the same as the new people whom will update gnome-sig packages after me. 

The gdk-pixbuf2 updates should be taken care of by Packit in the stable branches, then Jan (CC'ed) would need to update the Packit configuration file (for f44 and f43 as well), but that on its own won't prevent a human "mistake", whom may update the package in the future manually, not knowing of this decision we will-make/made here.

Put a comment in the spec file too?

Nobody reads comments, the less packit ;)

The update [1] received a green due to being tested and approved by more users. Can I pause it anyhow, or should I abort it? It is "paused" by the final freeze at the moment.

Personally, I would let it pass to the stable, it'll make the things simpler for the future, but I can understand it has also its downsides.

[1] https://bodhi.fedoraproject.org/updates/FEDORA-2026-b11f1d97f4

I'd suggest putting a big comment above (or on) the Version line in the f44 branch.  PR reviewers should see that, and I'll also be sure to speak up if I see a version bump PR in that branch.

If you log in to Bodhi, there should be a button to unsubmit the update, and then one to unpush it from updates-testing.

(FWIW, I think there's an argument that pushing .6 to a stable Fedora release would violate at least the spirit of the updates policy and/or the package retirement policy.)

> Nobody reads comments, the less packit ;)

But you already said you can update the packit config file. My suggestion was for the "a human "mistake", whom may update the package in the future manually" scenario.

My personal opinion is that we should withdraw the update for F44 at this point and leave things the way they are for F44's life.

Sure, works for me. I just unpushed the update (no idea what difference between revoke and unpush is, bodhi offered me both, I chose the later).

> I think there's an argument that pushing .6 to a stable Fedora release would violate at least the spirit of the updates policy

I would agree with that when it is 2.44.4 turning to 2.45.0, where one even expects soname version bumps and such when it touches the minor version, but the update is a micro version change, which are generally considered safe and stable updates (definitely by me). Not in the case of the gdk-pixbuf, obviously ;)

I reverted all the changes in the f44 branch and turned it back to the 2.44.4 version with a big warning in the .spec file, referencing this bug report:
https://src.fedoraproject.org/rpms/gdk-pixbuf2/c/7d3775560548a3ca53ea32ce33950288bc775b74?branch=f44

I've no idea how that Packit thingy works with respect of "do not dare to touch this branch", thus I'll ask Jan Grulich to make it the right thing. I'm afraid it should be even done in the rawhide branch, not in the f44 nor f43 branches, but, really, Packit is just a giant black box for me.

All is clear now, I'm closing this. Thank you for coordination and for the patience with me.

> I would agree with that when it is 2.44.4 turning to 2.45.0, where one even expects soname version bumps and such when it touches the minor version, but the update is a micro version change, which are generally considered safe and stable updates (definitely by me).

Sure, normally.  But obsoleting another source package and replacing the implementation of a format loader are larger changes.  Arguably they shouldn't have happened in an upstream micro release, but that's outside our control.

> All is clear now, I'm closing this. Thank you for coordination and for the patience with me.

Likewise, thanks for working through this.

> Sure, normally.  But obsoleting another source package and replacing the implementation of a format loader are larger changes.  Arguably they shouldn't have happened in an upstream micro release, but that's outside our control.

Yeah, there's also a technical point here, which is that we can no longer retire -extra from F44 at this point, I don't think, so even though there'd be a gdk-pixbuf2 update that 'obsoleted' it, it would still always be around and could be pulled in by dnf in various possible situations. Also, after release, the frozen release repos stick around, so we'd also always still have the non-obsoleting gdk-pixbuf2 from the frozen release repo available to dnf. So we'd wind up with a somewhat messy state in F44 if we pushed this update stable after release.

I'll poke the Workstation folks in Matrix to see if we can flag this not to be done as a post-release update via packit.

2.44.6 has now been pushed to F43 stable (FEDORA-2026-e5252a125b) without -Dlegacy_xpm=enabled, and is causing the expected breakage (bug 2459590) plus possibly some other breakage (bug 2460019).  The same change was pushed to F44 Git but not built.  @pschindl, you pushed directly without a PR, and in the F44 branch you ignored a giant "Do NOT update" comment block above the version number; why did you do this?

Per the discussion above, this will need to be rolled back in F43, and in F44 Git for safety.

An interesting bit on the f43 is that there did work fine even the 2.44.5, I suppose because the gdk-pixbuf2-extra-modules took care of the XPM loading (the rawhide/f44 obsoletes it). I'd expect it should work with 2.44.6 as well, for the same reason, but the time proofs my expectations are often false.

Revert the change, revert the change, it's not that easy, especially when it should be able to update (cannot just revert the commit) and when the upgrade path should work (f44 version should be higher than the f43 version). It might end up with those silly workarounds like "gdk-pixbuf2-2.44.6-3.really2.44.5.fc4X", I'm afraid.

> Revert the change, revert the change, it's not that easy, especially when it should be able to update (cannot just revert the commit) and when the upgrade path should work (f44 version should be higher than the f43 version). It might end up with those silly workarounds like "gdk-pixbuf2-2.44.6-3.really2.44.5.fc4X", I'm afraid.

Right, or an epoch bump all around.

I guess we want the JPEG security fix from 2.44.6.  One option might be to ship 2.44.6 to F43 and F44 but patch "legacy-xpm" back to "xpm" so the -modules-extra loader will work.  I don't know if bug 2460019 is a separate issue though.

Reported https://bugzilla.redhat.com/show_bug.cgi?id=2460118 earlier today.  Don't know if it's related to this.

I reverted the change for f44 in git, with added yelling to avoid human error. I could probably just revert, as it did not get anywhere and it was not built for the f44, but whatever. If anybody thinks it [1] is too much, I can simplify it by not using the "really..." in the Version tag.

As far as this f44 bug is concerned it's done, thus I'm re-closing this.

[1] https://src.fedoraproject.org/rpms/gdk-pixbuf2/c/3318fbb2bb715d1d7e99ce0f83e7f6625e952471?branch=f44

*** Bug 2451737 has been marked as a duplicate of this bug. ***

Good idea with the %prep script.  Thanks for fixing this up.