Control: clone -1 -2 Control: reassign -1 gcx 1.3-1.1 Control: retitle -1 gcx: aclocal.m4 contains outdated AM_PATH_GTK_2_0 which misuses AC_PATH_PROG Control: retitle -2 libglib2.0-dev: gtk-2.0.m4 does not have a serial number Control: tags -2 + upstream wontfix
On Fri, 06 Apr 2018 at 06:40:17 +0200, Helmut Grohne wrote: > This is essentially a clone of #894069. Same problem. Same patch. I know > AM_PATH_GTK_2_0 is deprecated, but gcx uses it and thus stumbles over > its use of AC_PATH_PROG finding the build architecture pkg-config. This was already fixed in GTK+ 2: $ grep AC_PATH_PROG /usr/share/aclocal/gtk-2.0.m4; echo $? 1 However, gcx doesn't run autoreconf, so the outdated copy in its aclocal.m4 is used instead of the copy in /usr/share/aclocal. This should be fixable by using dh-autoreconf (see dh-autoreconf(7)), although that might require patching the upstream build system to work with modern versions of Autoconf, Automake and Libtool. A related problem is that if a package has a bundled copy of gtk-2.0.m4 as a separate file in a m4/ or aclocal/ directory (gcx does not have this problem, but wxwidgets3.0 does), even if it runs autoreconf, aclocal will use the locally-bundled copy, because it can't know whether the locally-bundled copy is older or newer than the system copy. This is because gtk-2.0.m4 doesn't have an aclocal "serial number" (see `info automake Serials` for details). The cloned bug -2 represents this issue. The same thing seems to be widespread, so I'll try to write a Lintian check for it. I've used the "upstream wontfix" tags to indicate that Debian maintainers of libglib2.0-dev must not fix the cloned bug unilaterally: because the macros are part of source releases which might be made from any distribution, their serial numbers must be aligned between distributions. So we should only set a serial number *after* upstream does. smcv