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

[Michael Biebl]

Control: reassign -1 autoconf2.13

Am 26.07.2015 um 02:55 schrieb 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.

Given Ben's explanation, the autoconf wrapper in autoconf2.13 should be
able to detect if autoconf2.50 is supposed to be used.
Either that wrapper is fixed, or the diversions are removed.
In both cases, I this is something which needs to be addressed in
autoconf2.13, thus reassigning.

Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20150726/350e7706/attachment-0002.sig>