Bug#793647: systemd: missing build conflict vs autoconf2.13 - AM_COND_IF: no such condition ARCH_IA32
On Sun, Jul 26, 2015 at 03:30:58AM +0200, Michael Biebl wrote: Am 26.07.2015 um 02:55 schrieb Ben Pfaff: 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. I think so too. Apparently the wrapper is too brittle when it's used in combination with other build tools. I decided that I knew enough that it was time to remove the autoconf wrapper script. I've uploaded a new version of autoconf2.13, 2.13-64, to experimental. I would upload it to unstable, instead, except that I'm leaving Tuesday on a 2-week vacation and it seems irresponsible to make a major change and then leave without being able to immediately mop up any bugs that it causes. Anyway, please do feel free to take a look at it and let me know if you have any concerns. After I get back from vacation I'll contact the maintainers of packages that build-depend on autoconf2.13 and make sure they're aware of the impending change, and then I'll upload the new version to unstable. Thanks, Ben. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793647: systemd: missing build conflict vs autoconf2.13 - AM_COND_IF: no such condition ARCH_IA32
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? signature.asc Description: OpenPGP digital signature
Bug#793647: systemd: missing build conflict vs autoconf2.13 - AM_COND_IF: no such condition ARCH_IA32
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. Michael [1] dak finds ~800 packages build-depending directly on autoconf and 2600 depending on dh-autoreconf. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#793647: systemd: missing build conflict vs autoconf2.13 - AM_COND_IF: no such condition ARCH_IA32
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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793647: systemd: missing build conflict vs autoconf2.13 - AM_COND_IF: no such condition ARCH_IA32
Hi On 2015-07-25, Ben Pfaff wrote: On Sun, Jul 26, 2015 at 01:25:03AM +0200, Michael Biebl wrote: Am 25.07.2015 um 23:45 schrieb Alban Browaeys: [...] 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.) I can't speak for the systemd maintainers, but gummiboot has been merged into the upstream systemd source since systemd 220, which would explain this behaviour. Regards Stefan Lippers-Hollmann pgpkYLyPR8BC5.pgp Description: Digitale Signatur von OpenPGP
Bug#793647: systemd: missing build conflict vs autoconf2.13 - AM_COND_IF: no such condition ARCH_IA32
Am 26.07.2015 um 03:30 schrieb Michael Biebl: With v222, a simple autoreconf works, a intltoolize -f -c, autoreconf -f -i fails. That should be sufficient if you want to reproduce the issue. Actually, that's a red-herring. That said, I can reproduce the problem with $ dget -ux http://http.debian.net/debian/pool/main/s/systemd/systemd_222-2.dsc $ cd systemd-222 $ dpkg-buildpackage -us -uc -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#793647: systemd: missing build conflict vs autoconf2.13 - AM_COND_IF: no such condition ARCH_IA32
Hi Ben, thanks for your quick reply. Am 26.07.2015 um 02:55 schrieb Ben Pfaff: 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.) $ apt-cache policy autoconf autoconf2.13 autoconf: Installiert: 2.69-8 Installationskandidat: 2.69-8 Versionstabelle: *** 2.69-8 0 500 http://ftp.de.debian.org/debian/ sid/main amd64 Packages 100 /var/lib/dpkg/status autoconf2.13: Installiert: 2.13-63 Installationskandidat: 2.13-63 Versionstabelle: *** 2.13-63 0 500 http://ftp.de.debian.org/debian/ sid/main amd64 Packages 100 /var/lib/dpkg/status systemd's debian/rules runs: intltoolize -f -c autoreconf -f -i as part of the build process. With v222, a simple autoreconf works, a intltoolize -f -c, autoreconf -f -i fails. That should be sufficient if you want to reproduce the issue. 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. I think so too. Apparently the wrapper is too brittle when it's used in combination with other build tools. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
