1c4fb7e79a
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
Debugging reftest failures
==========================
In a local build
----------------
There must be a better way to do this, but this works...
top_srcdir=<path to unpacked package>
top_builddir=${srcdir}/debian/build/deb
srcdir=${srcdir}/testsuite/reftests
builddir=${builddir}/testsuite/reftests
cd "${builddir}"
debian/tests/run-with-display x11 \
dbus-run-session -- \
env \
-u XDG_RUNTIME_DIR \
REFTEST_MODULE_DIR="${builddir}" \
G_TEST_SRCDIR="${srcdir}" \
G_TEST_BUILDDIR="${builddir}" \
./gtk-reftest \
-o "${builddir}/output" \
-d "${srcdir}" \
-k \
2>&1 | tee test.log
Look for "not ok" in test.log.
Compare output/foo.ref.png and output/foo.out.png.
output/foo.diff.png shows an artificially-emphasized difference, if you
are having trouble spotting what is different.
On a buildd
-----------
You can't. Good luck reproducing it locally :-(