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
