If at some point in the future we have another transition as extensive
as time64, then libgtk-3-0t64 could conceivably be replaced by some
other package, which I have modelled here as libgtk-3-0xyz. If that
happens, we need to avoid deletion of immmodules.cache, otherwise
we will have another bug similar to #1065494.
This test-case depends on several implementation details of dpkg-repack
and libgtk-3-0t64, so it might need to be adjusted in the future. As
a result, I have marked it as flaky, so that failures in the official
autopkgtest environment will not be considered a release-critical bug
that stalls migration and requires immediate intervention by maintainers.
During the migration from libgtk-3-0 to libgtk-3-0t64, the package
that is responsible for "owning" /usr/lib/*/gtk-3.0/3.0.0/immodules.cache
changed from libgtk-3-0 to libgtk-3-0t64. Because dpkg does not have an
equivalent of RPM's %ghost files, the ownership of this file is managed
by social convention rather than by the package management system.
Unfortunately, libgtk-3-0's postrm as shipped in Debian releases from
2010 to the present is not aware of the possibility that another binary
package might need to take over responsibility for this file, and so
will remove it during purge (and in fact also during upgrades) in
accordance with the requirement that the package must not leave unowned
files behind. This causes input methods to be non-functional in GTK apps
until the next time the gtk-query-immodules-3.0 trigger happens to be run.
To disarm the problematic maintainer script, delete it during the new
package's preinst, similar to what was done for GLib in response
to #1065022.
A subsequent commit will improve the postrm so that if we find that we
need to migrate from libgtk-3-0t64 to libgtk-3-0xyz at some point in
the future, similar efforts will not be needed.
Closes: #1065494
Based on the reproducer I added to src:glib2.0 for the similar bug #1065022.
This one is simpler, because only architecture-specific multiarch files
are affected.
Use the systematic names gir1.2-cairo-1.0-dev, gir1.2-xlib-2.0-dev and
gir1.2-gio-2.0-dev if possible. The alternative dependency on
libgirepository1.0-dev illustrates how backports can be made to work.
gir1.2-atk-1.0-dev doesn't actually exist yet, so hide that one behind
a build-profile as a reminder to build-depend on it later.
Some of the listeners connected during the initial roundtrip assume a
non-NULL selection, when they finally invoke functions such as
gdk_wayland_selection_ensure_offer(),
gdk_wayland_selection_ensure_primary_offer() or
gdk_wayland_selection_set_offer(). The GdkWaylandSelection should
therefore be initialized before the second series of roundtrips, as the
compositor may have already sent a selection by then.
[NSView frame] returns a rectangle in the superview's coordinates, and the
superview of an NSWindow's content view (which is the only NSView that
GdkQuartz instantiates) is an undocumented NSThemeFrame. While it happens
to have the same origin as the content view and the same size as the
window's frame this isn't documented and so could change without notice.
Convert the window frame coordinates to the view's coordinate system to
ensure consistency.
Use the view's bounds instead of its frame: The bounds rectangle is in the
view's coordinate system. Use the parent NSWindow's frame instead of the
private NSThemeFrame's. This ensures that all coordinate comparisons have
the same reference.
Finally, the macOS coordinate systems origin is at the bottom left, so the
title bar is between the content view's height and the window's height,
not in negative y in the view's coordinates. Adjust the y comparisons
accordingly.
Fixes#6297
