Your message dated Sat, 26 Aug 2023 13:14:23 +0100 with message-id <ZOnsn2qdi9U/[email protected]> 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 [email protected] immediately.) -- 1043144: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043144 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: release.debian.org Severity: normal User: [email protected] Usertags: transition X-Debbugs-Cc: [email protected] 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 ---
