Re: GNOME 48 for Debian 13?

On Fri, 24 Jan 2025 16:19, Jeremy Bícha <[email protected]> wrote:
>The Trixie Freeze Schedule was released [1] this week, with dates
>later than we had originally expected when compared with the bookworm
>freeze schedule. I think it is possible for us to include GNOME 48 in
>Trixie so this starts discussion about whether to do that.
>
>Calendar Summary
>==========
>
>GNOME [2]
>----------
>2025-02-01 GNOME 48 Beta tarball deadline. This is also GNOME's UI,
>API, and Feature Freeze. For the past several release cycles, this is
>when we start landing the new GNOME in Debian Unstable (and Ubuntu's
>development release).
>2025-03-01 GNOME 48 RC tarball deadline
>2025-03-15 GNOME 48.0 tarball deadline
>2025-03-19 GNOME 48.0 release: This is a firm announcement/release
>date. Every other date on GNOME's calendar are tarball deadlines with
>the announced release days later.
>2025-04-12 GNOME 48.1 tarball deadline
>2025-05-** GNOME 48.2 tarball deadline. Not announced yet. My guess is
>it's after May 15 though.
>
>Debian [1] [3]
>----------
>2025-03-15 Transition freeze. Transitions need to be complete in
>Testing by this date.
>2025-04-15 Soft freeze. No new or returning packages allowed into
>Testing after this.
>2025-05-15 Hard freeze for key packages (includes everything that is a
>dependency of gnome) and packages without autopkgtests. We would need
>unblock requests starting here.
>
>Known Transitions
>==========
>1. GNOME Shell/Mutter. The GNOME Shell transition is simpler now that
>it's disconnected from Budgie. I got the new Mutter library package
>through Debian's NEW queue already. Usually, GNOME Shell has
>stabilized enough for extensions at the Beta point but no guarantee.
>We have about 5 weeks to get this transition done from the beta
>tarball release to transition freeze and then one more month for any
>straggling extensions to get back into Trixie. For 47, most extensions
>worked with a simple update to metadata.json and debian/control.
>
>2. glib/gtk/libadwaita. There aren't any issues with these in
>Experimental or in Ubuntu. glib and gtk need the most recent
>development releases packaged though.
>
>3. Rust GTK stack. There will not be a major Rust GTK stack
>update/transition for GNOME 48 in response to distribution complaints
>[4]. So this detail is much easier than it was for the past several
>GNOME releases.
>
>4. Glycin/rust-zbus transition [5]. Matthias Geiger has begun work on
>this. It affects Loupe and GNOME Snapshot but no other GNOME Core apps
>or GNOME libraries. We are waiting for some new rust-gufo* packages
>and rust-jpeg-encoder in the NEW queue. Still some more work needed
>but I think it's in good shape to land by early February if the NEW
>review is quick. Rust crates generally don't have versioned binary
>packages and therefore these transitions are not managed by the Debian
>Release Team currently.
Pretty much everything is staged in exp; and I was able tho build 
src:glycin 1.2~alpha with the gufo* packages from NEW, This will land 
image editing in Loupe, which will be a great thing to have for trixie.

>5. evolution-data-server. I already packaged the 48 Alpha release of
>the evolution* stack in Experimental and there is not a soname
>transition this time.
>
>6. Evince. Evince 48 Beta is expected to switch to GTK4. This would
>break everything using the Evince libraries (denemo, gnome-sushi,
>phosh-plugins, sugar-browse-activity, sugar-read-activity). Therefore,
>my plan is to package the new Evince in Experimental for evaluation.
>(I tried to do this for Evince 48 Alpha but the release was
>incomplete, mistakenly leaving out the gtk4 commits [6].) We would
>need a new source package, evince3, to repackage Evince 46, possibly
>only the libraries and not the app itself. Evince doesn't affect the
>rest of the GNOME stack really so we could choose to remain with 46 if
>we want.
>
>7. tracker -> tinysparql and tracker-miners -> localsearch. This is
>leftover from GNOME 47. Fedora and Ubuntu have yet to do this
>transition either. It is not required to otherwise package GNOME 47 or
>48. The renames are waiting in the NEW queue for experimental and then
>we need to verify whether the transition is smooth enough.
>
>8. I still think switching from gnome-terminal to ptyxis would be a
>good idea but I think we are blocked by bash [7] and possibly a screen
>reader regression [8]
>
>Conclusion
>==========
>That's a lot of details but I think we are in good shape to proceed
>with generally shipping GNOME 48. GNOME Shell and Glycin are the only
>core transitions we need.
>
>We should be able to get GNOME 48 RC in before the Transition Freeze
>and 48.1 in before the Hard Freeze. After that, we need unblocks or
>(soon enough) Stable Release Manager approval.
>
What about switching to Papers for 48 ? It's still stuck in NEW; though 
I guess we'll want to ship evince since Papers is largely untested ?

Maybe this could be backported from forky then.

best,

werdahias