On Mon, 27 Apr 2020 at 19:48:14 +0200, Pierre Cheynier wrote: > * upgrading my system except gnome-shell/mutter etc. > I tried to bump gir1.2-gnomedesktop-3.0, but this breaks gnome either > in 3.36.1-2 or 3.36.1-3 > (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956896). > May I suggest to add a "Breaks: gnome-shell (<< 3.36)" instead of > "Breaks: gnome-shell (<< 3.34)"? Or maybe I'm missing something?
What's meant to have happened is that gir1.2-gnomedesktop-3.0 Depends on libgnome-desktop-3-19, which Depends on a matching gnome-desktop3-data, which prevents installation of libgnome-desktop-3-18, which avoids the crash. The goal is that you can have either libgnome-desktop-3-19 or libgnome-desktop-3-18, but never both at the same time. This is not completely fixed in testing until libgnome-desktop-3-18_3.36.1-2 and gir1.2-gnomedesktop-3.0_3.36.1-2 disappear from testing, which should have happened 5 days ago but has been held up by some changes to other packages. If I'm reading the migration logs correctly, this is being delayed by the rebuilt version of evince having picked up a dependency on a newer libsecret, and might be solved in 2 days when libsecret is old enough to migrate. Increasing the version in the Breaks wouldn't really help you here, because gir1.2-gnomedesktop-3.0_3.36.1-2 didn't have it, and there's nothing we can do that will retroactively change version 3.36.1-2: we have to wait for the state of the archive to be suitable for version 3.36.1-2 to disappear. > * repackaging mutter 3.36.1+git20200419-1 with my revert of 59e9b073 > from upstream (context in the gnome thread > https://gitlab.gnome.org/GNOME/mutter/-/issues/1193#note_776408) > Unfortunately it requires libgnome-desktop-3-dev which depends on > gir1.2-gnomedesktop-3.0, same version, so I'm back to the first issue. > I can upgrade, compile, downgrade though. The best route would be to rebuild mutter against packages from unstable (in particular, with libgnome-desktop-3-dev_3.36.1-3 and libgnome-desktop-3-19 installed), with a revert of the commit(s) that you suspect are causing this. If you're able to build mutter in sbuild or pbuilder, in a container, or in a virtual machine, then the easiest way will be to do that, using an up-to-date unstable environment in the chroot/container/VM. Or you could upgrade to the unstable version of libgnome-desktop-3-19 (which will require upgrading gnome-shell and mutter to their latest versions from unstable, or at least a recent-ish version), and apply whatever workarounds make your system halfway usable for long enough to compile mutter with the problematic commit reverted. If this issue is Wayland-specific, maybe you could edit /etc/gdm3/daemon.conf and force X11 by uncommenting "WaylandEnable=false"; or you could temporarily disable gdm and use text mode to compile mutter. smcv