[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1043144: marked as done (transition: mutter/gnome-shell 44)

Your message dated Sat, 26 Aug 2023 13:14:23 +0100
with message-id <ZOnsn2qdi9U/9jtN@tautology.pseudorandom.co.uk>
and subject line Re: Bug#1043144: transition: mutter/gnome-shell 44
has caused the Debian Bug report #1043144,
regarding transition: mutter/gnome-shell 44
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1043144: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043144
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: transition
X-Debbugs-Cc: debian-gtk-gnome@lists.debian.org
Control: affects -1 + src:mutter src:gnome-shell
Control: block -1 by 1042980

It's about time we migrate GNOME Shell 44 to unstable. We delayed this for
a few months for the bookworm release, and then to get more testing for
the packages we wanted included in 12.1, but we should try to get 44 into
testing before upstream gets too close to releasing 45. Ubuntu already
did this transition for their 23.04 'lunar' short-term-support release.

This will require sourceful re-uploads of the following packages from
experimental into unstable, in approximately this order:

* mutter
* gnome-shell
* gnome-shell-extensions
* gnome-remote-desktop
* budgie-desktop
* gnome-shell-extension-bluetooth-quick-connect
* gnome-shell-extension-gsconnect

And then any remaining extensions in
https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=pkg-gnome-maintainers%40lists.alioth.debian.org&tag=gnome-shell-44
will need to be either fixed, re-uploaded from experimental to unstable
if already fixed in experimental, or temporarily kicked out of testing
to let the transition through.

There is one current blocker, #1042980, which is that gnome-shell is
failing build-time tests on mips64el and mipsel. So far I've fixed one
genuine bug in gnome-shell, and worked around another bug (seemingly in
LLVM or Mesa) by running the tests with softpipe rather than llvmpipe;
but there are still test failures. I don't think anyone in the GNOME
team has mips hardware or knowledge, and there's a limit to how usefully
we can debug this on eller. The failing test is new in v44, so we don't
know whether it would have failed in v43 if it existed there, or whether
it's a real regression: I've asked a mips porter to confirm whether Shell
v43 works with unstable's LLVM and Mesa or whether it is already broken,
but I haven't seen an answer so far.

Unlike s390x, I'm told mips(64)el does have desktop-class hardware that
could at least in principle run GNOME. I don't know how common that
hardware is, whether it's common to run GNOME on it, or whether mips
porters do so in practice (the extent of my information is "There are
some MIPS desktop cases").

Possible resolutions for #1042980:

* If mips porters can diagnose/fix the failing tests before we are
  otherwise ready to do this transition, then of course we should do that
  (but I think we need a contingency plan for if this doesn't happen)
* Or we could do architecture-specific removals on mips(64)el, making
  these uninstallable:
  - gdm3
  - gnome-core and other meta-gnome3 metapackages
  - gnome-session
  - ibus-tests
  - various Architecture: all packages such as Shell extensions
  - indirectly, task-gnome-desktop
* Or we could ignore the failing tests on mips(64)el, and let a
  potentially broken gnome-shell:mips(64)el into testing; and if the GNOME
  desktop has users on mips(64)el hardware who report that it doesn't work,
  ask mips porters to investigate and fix that

I feel as though holding back GNOME Shell 44 for the benefit of mips(64)el
users would be a worse result for Debian than getting GNOME 44 into
testing for the benefit of users of all the other architectures. Do
the release team have thoughts on which would be the best strategy to
avoid that?

Here is an attempt at a ben file that combines the mutter and gnome-shell
transitions, since they're really one transition:

title = "gnome-shell-44";
is_affected = .depends ~ /\b(gir1\.2\-mutter\-12|libmutter\-12\-0|libmutter\-12\-dev|libmutter\-test\-12|mutter\-12\-tests|gir1\.2\-mutter\-11|libmutter\-11\-0|libmutter\-11\-dev|libmutter\-test\-11|mutter\-11\-tests|gnome\-shell)\b/
is_good = .depends ~ /\b(gir1\.2\-mutter\-12|libmutter\-12\-0|libmutter\-12\-dev|libmutter\-test\-12|mutter\-12\-tests)\b/ | .depends ~ /gnome\-shell (<< 4[5-9]/ | !.depends ~ /gnome\-shell (<</;
is_bad = .depends ~ /\b(gir1\.2\-mutter\-11|libmutter\-11\-0|libmutter\-11\-dev|libmutter\-test\-11|mutter\-11\-tests)\b/ | .depends ~ /gnome\-shell (<< 44/;

Thanks,
    smcv

--- End Message ---
--- Begin Message --- 
On Sat, 26 Aug 2023 at 10:31:16 +0000, Graham Inggs wrote:
> libmutter-11-0 is gone from testing and gnome-shell has migrated.  Is
> anything outstanding, or can we consider this transition done?

Getting mutter and gnome-shell migrated was the main thing, so closing
this. The removed extensions will trickle back in if/when they are fixed.

FYI there will be another similar transition to be done
soon for GNOME 45, which is apparently going to involve
incompatible changes to most Shell extensions (like we had for
e.g. gnome-shell-extension-bluetooth-quick-connect, -gsconnect and
-tiling-assistant this time, but affecting a lot more of them). This is
a once per 6 months activity, but because we delayed this one so much,
the next will be sooner.

Thanks,
    smcv

--- End Message ---
Reply to: