Take over gtk-update-icon-cache from src:gtk+3.0

Not yet tested, and should go to experimental first.

@jbicha, do you think it's a good time to do this before the Ubuntu 24.04 deadline, or should we wait? We could either get this into testing before GTK 4.13/4.14, or entangle it with the transition to 4.13/4.14, or wait until after.

The practical difference is that in GTK4's update-icon-cache, we are not applying https://salsa.debian.org/gnome-team/gtk3/-/blob/debian/3.24.40-2/debian/patches/060_ignore-random-icons.patch?ref_type=tags (but according to upstream, it should no longer be necessary since 2008 anyway). We should check that the reproducer in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=444285#41 no longer breaks it.

assigned to @smcv

If you are not in a rush to get 4.13, I would personally be inclined to try to get this into testing first.

added 3 commits

• 6b729f96...8bd3555b - 2 commits from branch debian/latest
• 79c87bdc - Take over gtk-update-icon-cache from src:gtk+3.0

Compare with previous version

We would like to land 4.13 in Ubuntu this week, Jeremy has worked on it in wip/4.13.5 but got stuck on reftest issues. I said I would have a look to see if I can help him figure those out to unblock the update and it's on my todolist for this week now.

We can go ahead of Debian and only upload to Ubuntu if needed though.

I agree with 4.13 being a priority (for Ubuntu & Experimental). I'm also ok with having gtk4 take over gtk-update-icon-cache for Unstable & Ubuntu now.

Last cycle, a lot of GNOME apps required new libadwaita which required new gtk4 but libadwaita has not bumped its gtk4 requirement yet (yay!). Still good to get more testing on the new renderers though and there is not much time to gather data before GNOME starts freezing for release.

OK, I will hold this back while you look at doing 4.13.

Oops, this did not happen for 24.04 LTS but it's fine to land whenever

Immediately after a LTS or stable is probably the right time for this, tbh.

Might be easiest to land gtk 4.14 in Testing first?

But you could do it a different order if you want

Might be easiest to land gtk 4.14 in Testing first?

Yes, probably best, assuming we can land anything in testing ever again.

@smcv Here's a reminder in case you want to land this now before we start packaging gtk 4.15/4.16.

I think I'd prefer this sequence: get 4.14 into a state where it can migrate > do this > proceed with 4.15/4.16.

Or if you're in a hurry to start on 4.15, we could do 4.15 in experimental, also add this change in experimental at some point, and then if it all seems successful, cherry-pick this change into unstable.

(At the moment gtk4 can't migrate, because its autopkgtest fails on s390x, because clearly everyone wants to use OpenGL textures on their $10K mainframes, or something. I'm preparing patches to mitigate that.)

I am a bit rushed because I want to substantially package GNOME 47 Beta in 2 weeks in time for Ubuntu Feature Freeze and much of GNOME 47 will need gtk 4.15. But I can wait a few more days until we get 4.14 able to migrate.

I guess I can just include this change in the 4.15 packaging. I don't know if there is a need to do another 4.14 branched upload just for this change after we start the 4.15 packaging.

If you need to start on 4.15 urgently, please wait for the upload that is already compiling in a window over there ← so I can unblock 4.14, but then we can do the debian/latest/debian/trixie branching and get 4.15 into debian/latest if necessary.

(And you're welcome to start the process of importing 4.15 upstream source etc., too.)

I don't plan to work on 4.15 today. If everything looks good, maybe I'll work on it on Monday.

OK, great. I'm hoping that after this next upload, the only blocker for 4.14 will be rust-gdk4-sys (#1077741).

During the 4.15 cycle, it would be great if we could actually investigate test failures as we see them, rather than disabling/ignoring them and then having a problem and a deadline when we want to ship the stable release. I'm getting tired of being seemingly the only person doing this, because it makes me into upstream's punching bag for all architecture-specific things, which is really demotivating (every time mclasen grumbles about undefined behaviour or ports to non-x86, I feel as though I'm about to get banned for being an inconvenience).

If you need to start on 4.15 urgently, please wait for the upload that is already compiling in a window over there

mutex.release()

I'm hoping that after this next upload, the only blocker for 4.14 will be rust-gdk4-sys (#1077741)

werdahias uploaded a version that looks promising, so I'm hoping there are no more migration blockers. We'll see.

marked this merge request as ready

added 2638 commits

• 79c87bdc...3549a92b - 2637 commits from branch debian/latest
• 74eba477 - Take over gtk-update-icon-cache from src:gtk+3.0

Compare with previous version

merged