Re: GNOME 48 for Debian 13?
If GNOME 48 does make it in, what is the current status on X11 for 48?
It's rather unclear right now since
https://gitlab.gnome.org/GNOME/gnome-session/-/merge_requests/99 is
still open (and locked from further commenting) so I suppose it will
still be possible to use an X session until stated otherwise? I want
to stay on X for as long as possible, so I don't want to jump to
wayland just yet. I'm not saying this as a wayland vs x11 debate, but
rather my needs still need me on X for right now.
On Fri, Jan 24, 2025 at 10:29 AM Matthias Geiger <werdahias@riseup.net> wrote:
>
> On Fri, 24 Jan 2025 16:19, Jeremy Bícha <jeremy.bicha@canonical.com> 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
>
Reply to: