Bug#793647: systemd: missing build conflict vs autoconf2.13 - AM_COND_IF: no such condition "ARCH_IA32"

[Ben Pfaff]

On Sun, Jul 26, 2015 at 01:25:03AM +0200, Michael Biebl wrote:
> Am 25.07.2015 um 23:45 schrieb Alban Browaeys:
> > Package: systemd
> > Version: 222-2
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > Building systemd from package source, on arm 32 bits, I get :
> > configure.ac:1135: error: AM_COND_IF: no such condition "ARCH_IA32"
> > /usr/share/aclocal-1.15/cond-if.m4:23: AM_COND_IF is expanded from...
> > configure.ac:1135: the top level
> > autom4te: /usr/bin/m4 failed with exit status: 1
> > aclocal: error: echo failed with exit status: 1
> > autoreconf: aclocal failed with exit status: 1
> > debian/rules:257: recipe for target 'autoreconf' failed
> > make[2]: *** [autoreconf] Error 1
> > make[2]: Leaving directory '/home/prahal/Projects/Admin/systemd-222'
> > dh_autoreconf: debian/rules autoreconf returned exit code 2
> > debian/rules:261: recipe for target 'override_dh_autoreconf' failed
> > make[1]: *** [override_dh_autoreconf] Error 2
> > make[1]: Leaving directory '/home/prahal/Projects/Admin/systemd-222'
> > debian/rules:281: recipe for target 'build' failed
> > make: *** [build] Error 2
> > 
> > 
> >>From similar issue against gummiboot :
> >  https:bugs.debian.org/cgi-bin/bugreport.cgi?bug=754911 
> > there is a missing conflict with autoconf2.13.
> 
> I'm not convinced this makes sense.
> My gut feeling is, that we have several thousand source packages which
> have AC_PREREQ([>2.50]) in the archive and many packages nowadays run
> autoreconf during build [1]. Adding a Build-Conflicts against
> autconf2.13 to all of those packages seems like busy work without real gain.
> 
> I think, autoconf2.13 should stop diverting /usr/bin/autoconf and
> related binaries (autoheader, autoreconf).
> dak finds only 14 packages which require autoconf2.13. It makes much
> more sense to me, if those packages are updated to call
> /usr/bin/autoconf2.13 directly.
> 
> CCed the autoconf2.13 maintainer for their input.

The wrapper in the autoconf2.13 package is supposed to automatically
determine which version of Autoconf is necessary.  I see a bug, however,
which makes it fail to do that correctly with gummiboot.  I can fix
that, but I can't reproduce the same problem with systemd.

With gummiboot, I just had to type "autoreconf -f -i" to get the error
reported in bug #754911.  I don't see that error, though, when I do the
same with systemd (or if I run "dpkg-buildpackage").  Alban or Michael,
how do you see the problem?

(I tested against a slightly older systemd version, 215-17+deb8u1, not
version 222-2.  If there's been some important change since then, let me
know, and I'll retest.)

It might be time to remove the autoconf2.13 wrapper, since there is so
little software that still uses Autoconf 2.13, but I'd prefer to know
more about the bug first.

Thanks,

Ben.