Package: release.debian.org Severity: normal User: release.debian....@packages.debian.org Usertags: transition X-Debbugs-Cc: debian-gtk-gn...@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